https://wiki.scummvm.org/api.php?action=feedcontributions&user=Toneman&feedformat=atomScummVM :: Wiki - User contributions [en]2024-03-28T20:13:41ZUser contributionsMediaWiki 1.36.0https://wiki.scummvm.org/index.php?title=HOWTO-Dynamic_Modules&diff=14458HOWTO-Dynamic Modules2010-08-16T16:36:57Z<p>Toneman: </p>
<hr />
<div>NOTE: many parts of this HOWTO assume the "gsoc2010-plugins" branch has been integrated into trunk.<br />
<br />
=== Introduction ===<br />
<br />
This page is meant as a HOWTO which roughly outlines the steps needed to implement dynamic engine plugins for a previously unsupported backend (port) of ScummVM. This HOWTO only applies to targets that can use the ELF file-format and will generally only be useful for smaller targets that cannot support POSIX plugins. <br />
<br />
I will assume that you are at least roughly familiar with ScummVM, and have a fresh checkout of our Subversion repository. Note that it's strongly advised to base your work on the current development version of ScummVM, and not on a release version. This will ease integration of your work.<br />
<br />
=== Overview ===<br />
<br />
ScummVM has a PluginManager class that potentially keeps track of multiple plugin providers. As of this writing, a StaticPluginProvider is always added to this PluginManager that keeps track of all statically-linked plugins. Your job will be to add a dynamic plugin provider specific to the backend you're working on that will provide for any dynamic plugins that are enabled on that backend and to tell the backend to use this provider in the case that dynamic modules are enabled.<br />
<br />
=== Step by step ===<br />
<br />
For the rest of this document, I will assume you are attempting to implement loadable modules for the "foobar" port of ScummVM :-).<br />
<br />
# Create a new <code>backends/plugins</code> subdirectory matching the name of the port you're providing for, i.e. <tt>backends/plugins/foobar/</tt>.<br />
# Create a provider file in this subdirectory, such as <tt>foobar-provider.h</tt> that contains the class declaration of the provider for your port. This class should subtype ELFPluginProvider. This class should nest a class declaration that subtypes ELFPlugin but is specific to your port (i.e. <tt>FOOBARPlugin</tt>) and override ELFPluginProvider's "createPlugin" method with its own that returns a new FOOBARPlugin object (See example below).<br />
# The FOOBARPlugin class needs to override ELFPlugin's "makeDLObject" method and have it return a new object of an appropriate subclass of DLObject. Currently, the subclasses of DLObject are processor-specific, but depending on the port, you may find you have to subclass one of these processor-specific subclasses with a platform-specific one, such as <tt>FOOBARDLObject()</tt>. (See "Subclassing DLObject" below).<br />
# Find where <code>scummvm_main(argc, argv)</code> is invoked in your backend's main and somewhere shortly before it add the FOOBARPluginProvider to the PluginManager, i.e. <code>PluginManager::instance().addPluginProvider(new FOOBARPluginProvider();</code> (Be sure to guard this call with <code>#ifdef DYNAMIC_MODULES</code>). This, of course, will require that you include the FOOBARPluginProvider header at the top of the file.<br />
# Now we need to get the backend generating custom engine plugin files that can be loaded/unloaded to/from memory at will during runtime. To make the runtime linking (loading) of plugin files easier to handle, we let ld do some of the work for us at compile-time. First, we build the non-relocatable main executable <tt>scummvm.elf</tt> (Manually implementing Dynamic Modules on a smaller target that doesn't allow the main executable to be non-relocatable has not yet been successfully done and, as such, is not covered by this HOWTO). Then we link the plugins files together with a custom ld linker script; ld uses the absolute addresses from the main executable to resolve messy jumps from the plugin back to the main code and thus does much of the more complicated dynamic work for us. I would suggest adding the necessary custom linker script into the <tt>backends/plugins/foobar/</tt> directory you made earlier (See "Making the plugin linker script for your backend" below).<br />
# Modify the build system for your backend (See "Necessary Build Modifications" below).<br />
# Some miscellaneous things: You should add a platform-specific call to a function that flushes the data cache into <code>static void flushDataCache()</code> in <tt>backends/plugins/elf-loader.cpp</tt>. You will also need to add a check for the proper machine (processor) type into <code>bool DLObject::readElfHeader(Common::SeekableReadStream* DLFile, Elf32_Ehdr *ehdr)</code> in that same file, adding the machine type to elf32.h if it's not already there.<br />
# That's the gist of it; Cross your fingers and be prepared to work at things for a while if it doesn't immediately function ;-).<br />
<br />
==== Example of foobar-provider.h====<br />
<syntax type="C++">#if defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
<br />
#include "backends/plugins/elf-provider.h"<br />
#include "backends/plugins/foobarprocessor-loader.h"<br />
<br />
class FOOBARPluginProvider : public ELFPluginProvider {<br />
class FOOBARPlugin : public ELFPlugin {<br />
public:<br />
FOOBARPlugin(const Common::String &filename) : ELFPlugin(filename) {}<br />
<br />
DLObject *makeDLObject() { return new FOOBARProcessorDLObject(); }<br />
};<br />
<br />
public:<br />
Plugin* createPlugin(const Common::FSNode &node) const {<br />
return new FOOBARPlugin(node.getPath());<br />
}<br />
};<br />
<br />
#endif // defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
</syntax><br />
<br />
==== Making the plugin linker script for your backend ====<br />
To generate this script, first find the linker script used to link a static build of the target platform (usually this is the default script for the linker, which you can dump via the command <tt>foobar-compiler-ld --verbose</tt>). You'll want to modify this linker in a few key ways.<br />
<br />
*First, you can remove the <tt>ENTRY(symbol)</tt> command. This command normally tells the linker which instruction should be the first to execute in the program, but since you're generating a plugin that will be linked in and jumped to from the main executable, it is not needed. <br />
*Next, define an ELF program header for a "plugin" segment to be loaded from the file. Do this by adding the following before the SECTIONS command:<br />
<syntax type="C++">PHDRS<br />
{<br />
plugin PT_LOAD ;<br />
}</syntax><br />
*Set the start address of the file to be 0 (since this will be linked in at a different address later), usually you can do this by replacing the first line in SECTIONS with <code>. = 0;</code>, though different ld scripts may require different modifications.<br />
*Place the first section (as listed under the SECTIONS command) into the "plugin" segment you defined in PHDRS by appending <tt>:plugin</tt> to the first sections-command, i.e <code>.text . : { *(.text) } :plugin</code>. As long as there aren't any other PHDRS, this should ensure the entire linked file is put in the "plugin" segment, since future sections assume they are to be put in the same segment as the previous section unless specified otherwise (via <tt>:phdr</tt> or <tt>:NONE</tt>).<br />
*Find the <tt>.ctors</tt> and <tt>.dtors</tt> sections (constructors and destructors) and delete any output-section-commands within them that reference crtbegin or crtend, i.e <code>KEEP (*crtbegin*.o(.dtors))</code> or <code>KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))</code>. Put <code>___plugin_ctors = .;</code> as the first output-section-command in the <tt>.ctors</tt> section and <code>___plugin_ctors_end = .;</code> as the last output-section-command. Do the same for the <tt>.dtors</tt> section but with <tt>___plugin_dtors</tt>, etc. This gives these symbols values that our run-time loader can use. In the end, <tt>.ctors</tt> and <tt>.dtors</tt> should look something like this:<br />
<syntax type="C++">.ctors :<br />
{<br />
___plugin_ctors = .;<br />
KEEP (*(SORT(.ctors.*)))<br />
KEEP (*(.ctors))<br />
___plugin_ctors_end = .;<br />
}<br />
.dtors :<br />
{<br />
___plugin_dtors = .;<br />
KEEP (*(SORT(.dtors.*)))<br />
KEEP (*(.dtors))<br />
___plugin_dtors_end = .;<br />
}</syntax><br />
*That's it! If you have trouble with any of these instructions or need to further modify the linker script for something specific to your platform, see [http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html] for linker script documentation and peruse the various <tt>plugin.ld</tt> files in the subdirectories of <tt>backends/plugins/</tt>. TODO: Add stuff about MIPS-specific linker script modifications, namely the "shorts" segment.<br />
<br />
==== Necessary Build Modifications ====<br />
There will undoubtedly be a number of things specific to your platform to deal with when it comes to modifying the building, but you should definitely add the following, bordered by #ifdef guards to make sure DYNAMIC_MODULES is set to 1 (along with telling the desired engines that you want them to be separate plugin files, i.e. "ENABLE_SCUMM = DYNAMIC_PLUGIN"):<br />
<br />
<syntax type="C++">DEFINES += ELF_LOADER_TARGET //also add any other necessary defines<br />
PLUGIN_SUFFIX := .plg //or whatever your suffix is<br />
PLUGIN_EXTRA_DEPS = $(EXECUTABLE)<br />
PLUGIN_LDFLAGS += -nostartfiles -Wl,-q,--just-symbols,$(EXECUTABLE),-T$(srcdir)/backends/plugins/foobar/plugin.ld,--retain-symbols-file,$(srcdir)/backends/plugins/plugin.syms<br />
PRE_OBJS_FLAGS := -Wl,--whole-archive<br />
POST_OBJS_FLAGS := -Wl,--no-whole-archive<br />
</syntax><br />
<br />
As you can see, these modifications mainly deal with making sure the plugins are dependent on the main executable and use the custom linker script.<br />
<br />
You will also need to make sure your main executable is not being overly stripped as the thing doing the stripping may think the executable doesn't use certain symbols simply because they reference portions of code that will be linked in later in a plugin.<br />
<br />
TODO: Add stuff about "ONE_PLUGIN_AT_A_TIME" once it is working perfectly.<br />
<br />
==== Subclassing DLObject ====<br />
At some point, the PluginManager will call <code>getPlugins()</code> on the FOOBARProvider, which will trigger a search for plugin files in your backend's file system and return a list of FOOBARPlugins based on the results of this search. The PluginManager will then be able to call <code>loadplugin()</code> and <code>unloadPlugin</code> on any of these FOOBARPlugins, which will involve calls to <code>open(const char *path)</code> on a new object that's a subclass of DLObject (which subclass this will be is determined by how you coded <code>makeDLObject()</code> in your FOOBARPlugin class) with the path to the plugin file the FOOBARPlugin represents as its argument (The multiple levels of abstraction here can get confusing, I know :-)). A subclass of DLObject, then, is ultimately responsible for opening the plugin files and loading them/unloading them from memory.<br />
<br />
If there is already a DLObject subclass that matches the processor for your smaller target (i.e <tt>MIPSDLObject</tt>, <tt>ARMDLObject</tt>), use it! Assuming that class is in use for another working backend with dynamic modules implemented, most everything should work correctly. The one function where one should expect problems is <code>bool DLObject::relocate(Common::SeekableReadStream* DLFile, unsigned long offset, unsigned long size, void *relSegment)</code> in that your platform may generate plugins that use relocation types as of yet unsupported by that subclass of DLObject. If this is the case, you will hopefully get a helpful message at runtime, such as "Unknown relocation type 12" or something like that. You should then look up which relocation type this number refers to in the ABI for your processor (relocation types are processor-specific), add a define for the type into elf32.h next to the other relocation types for your processor (i.e. <code>#define R_ARM_ABS32 2</code>), and then add code to handle it into the relocate function (again, the ABI for your processor and pre-existing relocation code will be your friend when trying to figure this out).<br />
<br />
If there isn't already a DLObject subclass that matches the processor for your smaller target, you will have to make one that overrides <tt>relocate</tt> and <tt>relocateRels</tt>. You can look to these functions in <tt>backends/plugins/arm-loader.cpp</tt> and <tt>backends/plugins/mips-loader.cpp</tt> for a template of how to code for them. Again, the hardest part will be the code for the actual relocations. You'll want to first detect what these relocations are (you can do this using objdump on generated plugin files), then look up how they are supposed to be handled in the ABI for your processor. Since we pre-link to let ld do some of this relocation work for us, you should make builds that don't do this pre-linking with the plugins and ones that do and compare to see exactly what this work is. That way, you won't write relocation code for difficult things the linker already does for you (a lot of the time for absolute jumps, all you have to do is add the main offset of the plugin). Careful reading and persistence will pay off at this point :-)</div>Tonemanhttps://wiki.scummvm.org/index.php?title=HOWTO-Dynamic_Modules&diff=14444HOWTO-Dynamic Modules2010-08-16T08:17:23Z<p>Toneman: Filled out "subclassing DLObject"</p>
<hr />
<div>NOTE: many parts of this HOWTO assume the "gsoc2010-plugins" branch has been integrated into trunk.<br />
<br />
=== Introduction ===<br />
<br />
This page is meant as a HOWTO which roughly outlines the steps needed to implement dynamic engine plugins for a previously unsupported backend (port) of ScummVM. This HOWTO only applies to targets that can use the ELF file-format and will generally only be useful for smaller targets that cannot support POSIX plugins. <br />
<br />
I will assume that you are at least roughly familiar with ScummVM, and have a fresh checkout of our Subversion repository. Note that it's strongly advised to base your work on the current development version of ScummVM, and not on a release version. This will ease integration of your work.<br />
<br />
=== Overview ===<br />
<br />
ScummVM has a PluginManager class that potentially keeps track of multiple plugin providers. As of this writing, a StaticPluginProvider is always added to this PluginManager that keeps track of all statically-linked plugins. Your job will be to add a dynamic plugin provider specific to the backend you're working on that will provide for any dynamic plugins that are enabled on that backend and to tell the backend to use this provider in the case that dynamic modules are enabled.<br />
<br />
=== Step by step ===<br />
<br />
For the rest of this document, I will assume you are attempting to implement loadable modules for the "foobar" port of ScummVM :-).<br />
<br />
# Create a new <code>backends/plugins</code> subdirectory matching the name of the port you're providing for, i.e. <tt>backends/plugins/foobar/</tt>.<br />
# Create a provider file in this subdirectory, such as <tt>foobar-provider.h</tt> that contains the class declaration of the provider for your port. This class should subtype ELFPluginProvider. This class should nest a class declaration that subtypes ELFPlugin but is specific to your port (i.e. <tt>FOOBARPlugin</tt>) and override ELFPluginProvider's "createPlugin" method with its own that returns a new FOOBARPlugin object (See example below).<br />
# The FOOBARPlugin class needs to override ELFPlugin's "makeDLObject" method and have it return a new object of an appropriate subclass of DLObject. Currently, the subclasses of DLObject are processor-specific, but depending on the port, you may find you have to subclass one of these processor-specific subclasses with a platform-specific one, such as <tt>FOOBARDLObject()</tt>. (See "Subclassing DLObject" below).<br />
# Find where <code>scummvm_main(argc, argv)</code> is invoked in your backend's main and somewhere shortly before it add the FOOBARPluginProvider to the PluginManager, i.e. <code>PluginManager::instance().addPluginProvider(new FOOBARPluginProvider();</code> (Be sure to guard this call with <code>#ifdef DYNAMIC_MODULES</code>). This, of course, will require that you include the FOOBARPluginProvider header at the top of the file.<br />
# Now we need to get the backend generating custom engine plugin files that can be loaded/unloaded to/from memory at will during runtime. To make the runtime linking (loading) of plugin files easier to handle, we let ld do some of the work for us at compile-time. First, we build the non-relocatable main executable <tt>scummvm.elf</tt> (Manually implementing Dynamic Modules on a smaller target that doesn't allow the main executable to be non-relocatable has not yet been successfully done and, as such, is not covered by this HOWTO). Then we link the plugins files together with a custom ld linker script; ld uses the absolute addresses from the main executable to resolve messy jumps from the plugin back to the main code and thus does much of the more complicated dynamic work for us. I would suggest adding the necessary custom linker script into the <tt>backends/plugins/foobar/</tt> directory you made earlier (See "Making the plugin linker script for your backend" below).<br />
# Modify the build system for your backend (See "Necessary Build Modifications" below).<br />
# Some miscellaneous things: You should add a platform-specific call to a function that flushes the data cache into <code>static void flushDataCache()</code> in <tt>backends/plugins/elf-loader.cpp</tt>. You will also need to add a check for the proper machine (processor) type into <code>bool DLObject::readElfHeader(Common::SeekableReadStream* DLFile, Elf32_Ehdr *ehdr)</code> in that same file, adding the machine type to elf32.h if it's not already there.<br />
# That's the gist of it; Cross your fingers and be prepared to work at things for a while if it doesn't immediately function ;-).<br />
<br />
==== Example of foobar-provider.h====<br />
<syntax type="C++">#if defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
<br />
#include "backends/plugins/elf-provider.h"<br />
#include "backends/plugins/foobarprocessor-loader.h"<br />
<br />
class FOOBARPluginProvider : public ELFPluginProvider {<br />
class FOOBARPlugin : public ELFPlugin {<br />
public:<br />
FOOBARPlugin(const Common::String &filename) : ELFPlugin(filename) {}<br />
<br />
DLObject *makeDLObject() { return new FOOBARProcessorDLObject(); }<br />
};<br />
<br />
public:<br />
Plugin* createPlugin(const Common::FSNode &node) const {<br />
return new FOOBARPlugin(node.getPath());<br />
}<br />
};<br />
<br />
#endif // defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
</syntax><br />
<br />
==== Making the plugin linker script for your backend ====<br />
To generate this script, first find the linker script used to link a static build of the target platform (usually this is the default script for the linker, which you can dump via the command <tt>foobar-compiler-ld --verbose</tt>). You'll want to modify this linker in a few key ways.<br />
<br />
*First, you can remove the <tt>ENTRY(symbol)</tt> command. This command normally tells the linker which instruction should be the first to execute in the program, but since you're generating a plugin that will be linked in and jumped to from the main executable, it is not needed. <br />
*Next, define an ELF program header for a "plugin" segment to be loaded from the file. Do this by adding the following before the SECTIONS command:<br />
<syntax type="C++">PHDRS<br />
{<br />
plugin PT_LOAD ;<br />
}</syntax><br />
*Set the start address of the file to be 0 (since this will be linked in at a different address later), usually you can do this by replacing the first line in SECTIONS with <code>. = 0;</code>, though different ld scripts may require different modifications.<br />
*Place the first section (as listed under the SECTIONS command) into the "plugin" segment you defined in PHDRS by appending <tt>:plugin</tt> to the first sections-command, i.e <code>.text . : { *(.text) } :plugin</code>. As long as there aren't any other PHDRS, this should ensure the entire linked file is put in the "plugin" segment, since future sections assume they are to be put in the same segment as the previous section unless specified otherwise (via <tt>:phdr</tt> or <tt>:NONE</tt>).<br />
*Find the <tt>.ctors</tt> and <tt>.dtors</tt> sections (constructors and destructors) and delete any output-section-commands within them that reference crtbegin or crtend, i.e <code>KEEP (*crtbegin*.o(.dtors))</code> or <code>KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))</code>. Put <code>___plugin_ctors = .;</code> as the first output-section-command in the <tt>.ctors</tt> section and <code>___plugin_ctors_end = .;</code> as the last output-section-command. Do the same for the <tt>.dtors</tt> section but with <tt>___plugin_dtors</tt>, etc. This gives these symbols values that our run-time loader can use. In the end, <tt>.ctors</tt> and <tt>.dtors</tt> should look something like this:<br />
<syntax type="C++">.ctors :<br />
{<br />
___plugin_ctors = .;<br />
KEEP (*(SORT(.ctors.*)))<br />
KEEP (*(.ctors))<br />
___plugin_ctors_end = .;<br />
}<br />
.dtors :<br />
{<br />
___plugin_dtors = .;<br />
KEEP (*(SORT(.dtors.*)))<br />
KEEP (*(.dtors))<br />
___plugin_dtors_end = .;<br />
}</syntax><br />
*That's it! If you have trouble with any of these instructions or need to further modify the linker script for something specific to your platform, see [http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html] for linker script documentation and peruse the various <tt>plugin.ld</tt> files in the subdirectories of <tt>backends/plugins/</tt>. TODO: Add stuff about MIPS-specific linker script modifications, namely the "shorts" segment.<br />
<br />
==== Necessary Build Modifications ====<br />
There will undoubtedly be a number of things specific to your platform to deal with when it comes to modifying the building, but you should definitely add the following, bordered by #ifdef guards to make sure DYNAMIC_MODULES is set to 1 (along with telling the desired engines that you want them to be separate plugin files, i.e. "ENABLE_SCUMM = DYNAMIC_PLUGIN"):<br />
<br />
<syntax type="C++">DEFINES += ELF_LOADER_TARGET //also add any other necessary defines<br />
PLUGIN_SUFFIX := .plg //or whatever your suffix is<br />
PLUGIN_EXTRA_DEPS = $(EXECUTABLE)<br />
PLUGIN_LDFLAGS += -nostartfiles -Wl,-q,--just-symbols,$(EXECUTABLE),-T$(srcdir)/backends/plugins/foobar/plugin.ld,--retain-symbols-file,$(srcdir)/backends/plugins/plugin.syms<br />
PRE_OBJS_FLAGS := -Wl,--whole-archive<br />
POST_OBJS_FLAGS := -Wl,--no-whole-archive<br />
</syntax><br />
<br />
As you can see, these modifications mainly deal with making sure the plugins are dependent on the main executable and use the custom linker script.<br />
<br />
You will also need to make sure your main executable is not being overly stripped as the thing doing the stripping may think the executable doesn't use certain symbols simply because they reference portions of code that will be linked in later in a plugin.<br />
<br />
TODO: Add stuff about "ONE_PLUGIN_AT_A_TIME" once it is working perfectly.<br />
<br />
==== Subclassing DLObject ====<br />
At some point, the PluginManager will call <code>getPlugins()</code> on the FOOBARProvider, which will trigger a search for plugin files in your backend's file system and return a list of FOOBARPlugins based on the results of this search. The PluginManager will then be able to call <code>loadplugin()</code> and <code>unloadPlugin</code> on any of these FOOBARPlugins, which will involve calls to <code>open(const char *path)</code> on a new object that's a subclass of DLObject (which subclass this will be is determined by how you coded <code>makeDLObject()</code> in your FOOBARPlugin class) with the path to the plugin file the FOOBARPlugin represents as its argument (The multiple levels of abstraction here can get confusing, I know :-)). A subclass of DLObject, then, is ultimately responsible for opening the plugin files and loading them/unloading them from memory.<br />
<br />
If there is already a DLObject subclass that matches the processor for your smaller target (i.e <tt>MIPSDLObject</tt>, <tt>ARMDLObject</tt>), use it! Assuming that class is in use for another working backend with dynamic modules implemented, most everything should work correctly. The one function where one should expect problems is <code>bool DLObject::relocate(Common::SeekableReadStream* DLFile, unsigned long offset, unsigned long size, void *relSegment)</code> in that your platform may generate plugins that use relocation types as of yet unsupported by that subclass of DLObject. If this is the case, you will hopefully get a helpful message at runtime, such as "Unknown relocation type 12" or something like that. You should then look up which relocation type this number refers to in the ABI for your processor (relocation types are processor-specific), add a define for the type into elf32.h next to the other relocation types for your processor (i.e. <code>#define R_ARM_ABS32 2</code>), and then add code to handle it into the relocate function (again, the ABI for your processor and pre-existing relocation code will be your friend when trying to figure this out).<br />
<br />
If there isn't already a DLObject subclass that matches the processor for your smaller target, you will have to make one that overrides <tt>relocate</tt> and <tt>relocateRels</tt>. You can look to these functions in <tt>backends/plugins/arm-loader.cpp</tt> and <tt>backends/plugins/mips-loader.cpp</tt> for a template of how to code for them. Again, the hardest part will be the code for the actual relocations. You'll want to first detect what these relocations are (you can do this using objdump on generated plugin files), then look up how they are supposed to be handled in the ABI for your processor. Since we pre-link to let ld do some of this relocation work for us, you should make builds that don't do this pre-linking with the plugins and ones that do and compare to see exactly what this work is. That way, you won't write relocation code for difficult things the linker already does for you. Careful reading and persistence will pay off at this point :-)</div>Tonemanhttps://wiki.scummvm.org/index.php?title=HOWTO-Dynamic_Modules&diff=14442HOWTO-Dynamic Modules2010-08-16T07:28:37Z<p>Toneman: </p>
<hr />
<div>NOTE: many parts of this HOWTO assume the "gsoc2010-plugins" branch has been integrated into trunk.<br />
<br />
=== Introduction ===<br />
<br />
This page is meant as a HOWTO which roughly outlines the steps needed to implement dynamic engine plugins for a previously unsupported backend (port) of ScummVM. This HOWTO only applies to targets that can use the ELF file-format and will generally only be useful for smaller targets that cannot support POSIX plugins. <br />
<br />
I will assume that you are at least roughly familiar with ScummVM, and have a fresh checkout of our Subversion repository. Note that it's strongly advised to base your work on the current development version of ScummVM, and not on a release version. This will ease integration of your work.<br />
<br />
=== Overview ===<br />
<br />
ScummVM has a PluginManager class that potentially keeps track of multiple plugin providers. As of this writing, a StaticPluginProvider is always added to this PluginManager that keeps track of all statically-linked plugins. Your job will be to add a dynamic plugin provider specific to the backend you're working on that will provide for any dynamic plugins that are enabled on that backend and to tell the backend to use this provider in the case that dynamic modules are enabled.<br />
<br />
=== Step by step ===<br />
<br />
For the rest of this document, I will assume you are attempting to implement loadable modules for the "foobar" port of ScummVM :-).<br />
<br />
# Create a new <code>backends/plugins</code> subdirectory matching the name of the port you're providing for, i.e. <tt>backends/plugins/foobar/</tt>.<br />
# Create a provider file in this subdirectory, such as <tt>foobar-provider.h</tt> that contains the class declaration of the provider for your port. This class should subtype ELFPluginProvider. This class should nest a class declaration that subtypes ELFPlugin but is specific to your port (i.e. <tt>FOOBARPlugin</tt>) and override ELFPluginProvider's "createPlugin" method with its own that returns a new FOOBARPlugin object (See example below).<br />
# The FOOBARPlugin class needs to override ELFPlugin's "makeDLObject" method and have it return a new object of an appropriate subclass of DLObject. Currently, the subclasses of DLObject are processor-specific, but depending on the port, you may find you have to subclass one of these processor-specific subclasses with a platform-specific one, such as <tt>FOOBARDLObject()</tt>. (See "Subclassing DLObject" below).<br />
# Find where <code>scummvm_main(argc, argv)</code> is invoked in your backend's main and somewhere shortly before it add the FOOBARPluginProvider to the PluginManager, i.e. <code>PluginManager::instance().addPluginProvider(new FOOBARPluginProvider();</code> (Be sure to guard this call with <code>#ifdef DYNAMIC_MODULES</code>). This, of course, will require that you include the FOOBARPluginProvider header at the top of the file.<br />
# Now we need to get the backend generating custom engine plugin files that can be loaded/unloaded to/from memory at will during runtime. To make the runtime linking (loading) of plugin files easier to handle, we let ld do some of the work for us at compile-time. First, we build the non-relocatable main executable <tt>scummvm.elf</tt> (Manually implementing Dynamic Modules on a smaller target that doesn't allow the main executable to be non-relocatable has not yet been successfully done and, as such, is not covered by this HOWTO). Then we link the plugins files together with a custom ld linker script; ld uses the absolute addresses from the main executable to resolve messy jumps from the plugin back to the main code and thus does much of the more complicated dynamic work for us. I would suggest adding the necessary custom linker script into the <tt>backends/plugins/foobar/</tt> directory you made earlier (See "Making the plugin linker script for your backend" below).<br />
# Modify the build system for your backend (See "Necessary Build Modifications" below).<br />
# Cross your fingers and be prepared to work at things for a while if it doesn't immediately function ;-)<br />
<br />
==== Example of foobar-provider.h====<br />
<syntax type="C++">#if defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
<br />
#include "backends/plugins/elf-provider.h"<br />
#include "backends/plugins/foobarprocessor-loader.h"<br />
<br />
class FOOBARPluginProvider : public ELFPluginProvider {<br />
class FOOBARPlugin : public ELFPlugin {<br />
public:<br />
FOOBARPlugin(const Common::String &filename) : ELFPlugin(filename) {}<br />
<br />
DLObject *makeDLObject() { return new FOOBARProcessorDLObject(); }<br />
};<br />
<br />
public:<br />
Plugin* createPlugin(const Common::FSNode &node) const {<br />
return new FOOBARPlugin(node.getPath());<br />
}<br />
};<br />
<br />
#endif // defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
</syntax><br />
<br />
==== Making the plugin linker script for your backend ====<br />
To generate this script, first find the linker script used to link a static build of the target platform (usually this is the default script for the linker, which you can dump via the command <tt>foobar-compiler-ld --verbose</tt>). You'll want to modify this linker in a few key ways.<br />
<br />
*First, you can remove the <tt>ENTRY(symbol)</tt> command. This command normally tells the linker which instruction should be the first to execute in the program, but since you're generating a plugin that will be linked in and jumped to from the main executable, it is not needed. <br />
*Next, define an ELF program header for a "plugin" segment to be loaded from the file. Do this by adding the following before the SECTIONS command:<br />
<syntax type="C++">PHDRS<br />
{<br />
plugin PT_LOAD ;<br />
}</syntax><br />
*Set the start address of the file to be 0 (since this will be linked in at a different address later), usually you can do this by replacing the first line in SECTIONS with <code>. = 0;</code>, though different ld scripts may require different modifications.<br />
*Place the first section (as listed under the SECTIONS command) into the "plugin" segment you defined in PHDRS by appending <tt>:plugin</tt> to the first sections-command, i.e <code>.text . : { *(.text) } :plugin</code>. As long as there aren't any other PHDRS, this should ensure the entire linked file is put in the "plugin" segment, since future sections assume they are to be put in the same segment as the previous section unless specified otherwise (via <tt>:phdr</tt> or <tt>:NONE</tt>).<br />
*Find the <tt>.ctors</tt> and <tt>.dtors</tt> sections (constructors and destructors) and delete any output-section-commands within them that reference crtbegin or crtend, i.e <code>KEEP (*crtbegin*.o(.dtors))</code> or <code>KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))</code>. Put <code>___plugin_ctors = .;</code> as the first output-section-command in the <tt>.ctors</tt> section and <code>___plugin_ctors_end = .;</code> as the last output-section-command. Do the same for the <tt>.dtors</tt> section but with <tt>___plugin_dtors</tt>, etc. This gives these symbols values that our run-time loader can use. In the end, <tt>.ctors</tt> and <tt>.dtors</tt> should look something like this:<br />
<syntax type="C++">.ctors :<br />
{<br />
___plugin_ctors = .;<br />
KEEP (*(SORT(.ctors.*)))<br />
KEEP (*(.ctors))<br />
___plugin_ctors_end = .;<br />
}<br />
.dtors :<br />
{<br />
___plugin_dtors = .;<br />
KEEP (*(SORT(.dtors.*)))<br />
KEEP (*(.dtors))<br />
___plugin_dtors_end = .;<br />
}</syntax><br />
*That's it! If you have trouble with any of these instructions or need to further modify the linker script for something specific to your platform, see [http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html] for linker script documentation and peruse the various <tt>plugin.ld</tt> files in the subdirectories of <tt>backends/plugins/</tt>. TODO: Add stuff about MIPS-specific linker script modifications, namely the "shorts" segment.<br />
<br />
==== Necessary Build Modifications ====<br />
There will undoubtedly be a number of things specific to your platform to deal with when it comes to modifying the building, but you should definitely add the following, bordered by #ifdef guards to make sure DYNAMIC_MODULES is set to 1 (along with telling the desired engines that you want them to be separate plugin files, i.e. "ENABLE_SCUMM = DYNAMIC_PLUGIN"):<br />
<br />
<syntax type="C++">DEFINES += ELF_LOADER_TARGET //also add any other necessary defines<br />
PLUGIN_SUFFIX := .plg //or whatever your suffix is<br />
PLUGIN_EXTRA_DEPS = $(EXECUTABLE)<br />
PLUGIN_LDFLAGS += -nostartfiles -Wl,-q,--just-symbols,$(EXECUTABLE),-T$(srcdir)/backends/plugins/foobar/plugin.ld,--retain-symbols-file,$(srcdir)/backends/plugins/plugin.syms<br />
PRE_OBJS_FLAGS := -Wl,--whole-archive<br />
POST_OBJS_FLAGS := -Wl,--no-whole-archive<br />
</syntax><br />
<br />
As you can see, these modifications mainly deal with making sure the plugins are dependent on the main executable and use the custom linker script.<br />
<br />
You will also need to make sure your main executable is not being overly stripped as the thing doing the stripping may think the executable doesn't use certain symbols simply because they reference portions of code that will be linked in later in a plugin.<br />
<br />
TODO: Add stuff about "ONE_PLUGIN_AT_A_TIME" once it is working perfectly.<br />
<br />
==== Subclassing DLObject ====<br />
At some point, the PluginManager will call <code>getPlugins()</code> on the FOOBARProvider, which will trigger a search for plugin files in your backend's file system and return a list of FOOBARPlugins based on the results of this search. The PluginManager will then be able to call <code>loadplugin()</code> and <code>unloadPlugin</code>, and on any of these FOOBARPlugins, which will involve calls to <code>open(const char *path)</code> on a new object that's a subclass of DLObject (which subclass is determined by how you coded <code>makeDLObject()</code> in the FOOBARPlugin class) with the path to the plugin file the FOOBARPlugin represents as its argument (The multiple levels of abstraction here can get confusing :-)). A subclass of DLObject, then, is ultimately responsible for opening the plugin files and loading them/unloading them from memory.<br />
<br />
TODO: Finish explaining what the DLObject class does and how to subclass it effectively.</div>Tonemanhttps://wiki.scummvm.org/index.php?title=HOWTO-Dynamic_Modules&diff=14441HOWTO-Dynamic Modules2010-08-16T07:26:34Z<p>Toneman: </p>
<hr />
<div>NOTE: many parts of this HOWTO assume the "gsoc2010-plugins" branch has been integrated into trunk.<br />
<br />
=== Introduction ===<br />
<br />
This page is meant as a HOWTO which roughly outlines the steps needed to implement dynamic engine plugins for a previously unsupported backend (port) of ScummVM. This HOWTO only applies to targets that can use the ELF file-format and will generally only be useful for smaller targets that cannot support POSIX plugins. <br />
<br />
I will assume that you are at least roughly familiar with ScummVM, and have a fresh checkout of our Subversion repository. Note that it's strongly advised to base your work on the current development version of ScummVM, and not on a release version. This will ease integration of your work.<br />
<br />
<br />
=== Overview ===<br />
<br />
ScummVM has a PluginManager class that potentially keeps track of multiple plugin providers. As of this writing, a StaticPluginProvider is always added to this PluginManager that keeps track of all statically-linked plugins. Your job will be to add a dynamic plugin provider specific to the backend you're working on that will provide for any dynamic plugins that are enabled on that backend and to tell the backend to use this provider in the case that dynamic modules are enabled.<br />
<br />
<br />
=== Step by step ===<br />
<br />
For the rest of this document, I will assume you are attempting to implement loadable modules for the "foobar" port of ScummVM :-).<br />
<br />
# Create a new <code>backends/plugins</code> subdirectory matching the name of the port you're providing for, i.e. <tt>backends/plugins/foobar/</tt>.<br />
# Create a provider file in this subdirectory, such as <tt>foobar-provider.h</tt> that contains the class declaration of the provider for your port. This class should subtype ELFPluginProvider. This class should nest a class declaration that subtypes ELFPlugin but is specific to your port (i.e. <tt>FOOBARPlugin</tt>) and override ELFPluginProvider's "createPlugin" method with its own that returns a new FOOBARPlugin object (See example below).<br />
# The FOOBARPlugin class needs to override ELFPlugin's "makeDLObject" method and have it return a new object of an appropriate subclass of DLObject. Currently, the subclasses of DLObject are processor-specific, but depending on the port, you may find you have to subclass one of these processor-specific subclasses with a platform-specific one, such as <tt>FOOBARDLObject()</tt>. (See "Subclassing DLObject" below).<br />
# Find where <code>scummvm_main(argc, argv)</code> is invoked in your backend's main and somewhere shortly before it add the FOOBARPluginProvider to the PluginManager, i.e. <code>PluginManager::instance().addPluginProvider(new FOOBARPluginProvider();</code> (Be sure to guard this call with <code>#ifdef DYNAMIC_MODULES</code>). This, of course, will require that you include the FOOBARPluginProvider header at the top of the file.<br />
# Now we need to get the backend generating custom engine plugin files that can be loaded/unloaded to/from memory at will during runtime. To make the runtime linking (loading) of plugin files easier to handle, we let ld do some of the work for us at compile-time. First, we build the non-relocatable main executable <tt>scummvm.elf</tt> (Manually implementing Dynamic Modules on a smaller target that doesn't allow the main executable to be non-relocatable has not yet been successfully done and, as such, is not covered by this HOWTO). Then we link the plugins files together with a custom ld linker script; ld uses the absolute addresses from the main executable to resolve messy jumps from the plugin back to the main code and thus does much of the more complicated dynamic work for us. I would suggest adding the necessary custom linker script into the <tt>backends/plugins/foobar/</tt> directory you made earlier (See "Making the plugin linker script for your backend" below).<br />
# Modify the build system for your backend (See "Necessary Build Modifications" below).<br />
# Cross your fingers and be prepared to work at things for a while if it doesn't immediately function ;-)<br />
<br />
<br />
==== Example of foobar-provider.h====<br />
<syntax type="C++">#if defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
<br />
#include "backends/plugins/elf-provider.h"<br />
#include "backends/plugins/foobarprocessor-loader.h"<br />
<br />
class FOOBARPluginProvider : public ELFPluginProvider {<br />
class FOOBARPlugin : public ELFPlugin {<br />
public:<br />
FOOBARPlugin(const Common::String &filename) : ELFPlugin(filename) {}<br />
<br />
DLObject *makeDLObject() { return new FOOBARProcessorDLObject(); }<br />
};<br />
<br />
public:<br />
Plugin* createPlugin(const Common::FSNode &node) const {<br />
return new FOOBARPlugin(node.getPath());<br />
}<br />
};<br />
<br />
#endif // defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
</syntax><br />
<br />
<br />
==== Making the plugin linker script for your backend ====<br />
To generate this script, first find the linker script used to link a static build of the target platform (usually this is the default script for the linker, which you can dump via the command <tt>foobar-compiler-ld --verbose</tt>). You'll want to modify this linker in a few key ways.<br />
<br />
*First, you can remove the <tt>ENTRY(symbol)</tt> command. This command normally tells the linker which instruction should be the first to execute in the program, but since you're generating a plugin that will be linked in and jumped to from the main executable, it is not needed. <br />
*Next, define an ELF program header for a "plugin" segment to be loaded from the file. Do this by adding the following before the SECTIONS command:<br />
<syntax type="C++">PHDRS<br />
{<br />
plugin PT_LOAD ;<br />
}</syntax><br />
*Set the start address of the file to be 0 (since this will be linked in at a different address later), usually you can do this by replacing the first line in SECTIONS with <code>. = 0;</code>, though different ld scripts may require different modifications.<br />
*Place the first section (as listed under the SECTIONS command) into the "plugin" segment you defined in PHDRS by appending <tt>:plugin</tt> to the first sections-command, i.e <code>.text . : { *(.text) } :plugin</code>. As long as there aren't any other PHDRS, this should ensure the entire linked file is put in the "plugin" segment, since future sections assume they are to be put in the same segment as the previous section unless specified otherwise (via <tt>:phdr</tt> or <tt>:NONE</tt>).<br />
*Find the <tt>.ctors</tt> and <tt>.dtors</tt> sections (constructors and destructors) and delete any output-section-commands within them that reference crtbegin or crtend, i.e <code>KEEP (*crtbegin*.o(.dtors))</code> or <code>KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))</code>. Put <code>___plugin_ctors = .;</code> as the first output-section-command in the <tt>.ctors</tt> section and <code>___plugin_ctors_end = .;</code> as the last output-section-command. Do the same for the <tt>.dtors</tt> section but with <tt>___plugin_dtors</tt>, etc. This gives these symbols values that our run-time loader can use. In the end, <tt>.ctors</tt> and <tt>.dtors</tt> should look something like this:<br />
<syntax type="C++">.ctors :<br />
{<br />
___plugin_ctors = .;<br />
KEEP (*(SORT(.ctors.*)))<br />
KEEP (*(.ctors))<br />
___plugin_ctors_end = .;<br />
}<br />
.dtors :<br />
{<br />
___plugin_dtors = .;<br />
KEEP (*(SORT(.dtors.*)))<br />
KEEP (*(.dtors))<br />
___plugin_dtors_end = .;<br />
}</syntax><br />
*That's it! If you have trouble with any of these instructions or need to further modify the linker script for something specific to your platform, see [http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html] for linker script documentation and peruse the various <tt>plugin.ld</tt> files in the subdirectories of <tt>backends/plugins/</tt>. TODO: Add stuff about MIPS-specific linker script modifications, namely the "shorts" segment.<br />
<br />
<br />
==== Necessary Build Modifications ====<br />
There will undoubtedly be a number of things specific to your platform to deal with when it comes to modifying the building, but you should definitely add the following, bordered by #ifdef guards to make sure DYNAMIC_MODULES is set to 1 (along with telling the desired engines that you want them to be separate plugin files, i.e. "ENABLE_SCUMM = DYNAMIC_PLUGIN"):<br />
<br />
<syntax type="C++">DEFINES += ELF_LOADER_TARGET //also add any other necessary defines<br />
PLUGIN_SUFFIX := .plg //or whatever your suffix is<br />
PLUGIN_EXTRA_DEPS = $(EXECUTABLE)<br />
PLUGIN_LDFLAGS += -nostartfiles -Wl,-q,--just-symbols,$(EXECUTABLE),-T$(srcdir)/backends/plugins/foobar/plugin.ld,--retain-symbols-file,$(srcdir)/backends/plugins/plugin.syms<br />
PRE_OBJS_FLAGS := -Wl,--whole-archive<br />
POST_OBJS_FLAGS := -Wl,--no-whole-archive<br />
</syntax><br />
<br />
As you can see, these modifications mainly deal with making sure the plugins are dependent on the main executable and use the custom linker script.<br />
<br />
You will also need to make sure your main executable is not being overly stripped as the thing doing the stripping may think the executable doesn't use certain symbols simply because they reference portions of code that will be linked in later in a plugin.<br />
<br />
TODO: Add stuff about "ONE_PLUGIN_AT_A_TIME" once it is working perfectly.<br />
<br />
<br />
==== Subclassing DLObject ====<br />
At some point, the PluginManager will call <code>getPlugins()</code> on the FOOBARProvider, which will trigger a search for plugin files in your backend's file system and return a list of FOOBARPlugins based on the results of this search. The PluginManager will then be able to call <code>loadplugin()</code> and <code>unloadPlugin</code>, and on any of these FOOBARPlugins, which will involve calls to <code>open(const char *path)</code> on a new object that's a subclass of DLObject (which subclass is determined by how you coded <code>makeDLObject()</code> in the FOOBARPlugin class) with the path to the plugin file the FOOBARPlugin represents as its argument (The multiple levels of abstraction here can get confusing :-)). A subclass of DLObject, then, is ultimately responsible for opening the plugin files and loading them/unloading them from memory.<br />
<br />
TODO: Finish explaining what the DLObject class does and how to subclass it effectively.</div>Tonemanhttps://wiki.scummvm.org/index.php?title=HOWTO-Dynamic_Modules&diff=14440HOWTO-Dynamic Modules2010-08-16T07:23:54Z<p>Toneman: Filled out the "making the plugin linker script for your backend"</p>
<hr />
<div>NOTE: many parts of this HOWTO assume the "gsoc2010-plugins" branch has been integrated into trunk.<br />
<br />
=== Introduction ===<br />
<br />
This page is meant as a HOWTO which roughly outlines the steps needed to implement dynamic engine plugins for a previously unsupported backend (port) of ScummVM. This HOWTO only applies to targets that can use the ELF file-format and will generally only be useful for smaller targets that cannot support POSIX plugins. <br />
<br />
I will assume that you are at least roughly familiar with ScummVM, and have a fresh checkout of our Subversion repository. Note that it's strongly advised to base your work on the current development version of ScummVM, and not on a release version. This will ease integration of your work.<br />
<br />
=== Overview ===<br />
<br />
ScummVM has a PluginManager class that potentially keeps track of multiple plugin providers. As of this writing, a StaticPluginProvider is always added to this PluginManager that keeps track of all statically-linked plugins. Your job will be to add a dynamic plugin provider specific to the backend you're working on that will provide for any dynamic plugins that are enabled on that backend and to tell the backend to use this provider in the case that dynamic modules are enabled.<br />
<br />
=== Step by step ===<br />
<br />
For the rest of this document, I will assume you are attempting to implement loadable modules for the "foobar" port of ScummVM :-).<br />
<br />
# Create a new <code>backends/plugins</code> subdirectory matching the name of the port you're providing for, i.e. <tt>backends/plugins/foobar/</tt>.<br />
# Create a provider file in this subdirectory, such as <tt>foobar-provider.h</tt> that contains the class declaration of the provider for your port. This class should subtype ELFPluginProvider. This class should nest a class declaration that subtypes ELFPlugin but is specific to your port (i.e. <tt>FOOBARPlugin</tt>) and override ELFPluginProvider's "createPlugin" method with its own that returns a new FOOBARPlugin object (See example below).<br />
# The FOOBARPlugin class needs to override ELFPlugin's "makeDLObject" method and have it return a new object of an appropriate subclass of DLObject. Currently, the subclasses of DLObject are processor-specific, but depending on the port, you may find you have to subclass one of these processor-specific subclasses with a platform-specific one, such as <tt>FOOBARDLObject()</tt>. (See "Subclassing DLObject" below).<br />
# Find where <code>scummvm_main(argc, argv)</code> is invoked in your backend's main and somewhere shortly before it add the FOOBARPluginProvider to the PluginManager, i.e. <code>PluginManager::instance().addPluginProvider(new FOOBARPluginProvider();</code> (Be sure to guard this call with <code>#ifdef DYNAMIC_MODULES</code>). This, of course, will require that you include the FOOBARPluginProvider header at the top of the file.<br />
# Now we need to get the backend generating custom engine plugin files that can be loaded/unloaded to/from memory at will during runtime. To make the runtime linking (loading) of plugin files easier to handle, we let ld do some of the work for us at compile-time. First, we build the non-relocatable main executable <tt>scummvm.elf</tt> (Manually implementing Dynamic Modules on a smaller target that doesn't allow the main executable to be non-relocatable has not yet been successfully done and, as such, is not covered by this HOWTO). Then we link the plugins files together with a custom ld linker script; ld uses the absolute addresses from the main executable to resolve messy jumps from the plugin back to the main code and thus does much of the more complicated dynamic work for us. I would suggest adding the necessary custom linker script into the <tt>backends/plugins/foobar/</tt> directory you made earlier (See "Making the plugin linker script for your backend" below).<br />
# Modify the build system for your backend (See "Necessary Build Modifications" below).<br />
# Cross your fingers and be prepared to work at things for a while if it doesn't immediately function ;-)<br />
<br />
==== Example of foobar-provider.h====<br />
<syntax type="C++">#if defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
<br />
#include "backends/plugins/elf-provider.h"<br />
#include "backends/plugins/foobarprocessor-loader.h"<br />
<br />
class FOOBARPluginProvider : public ELFPluginProvider {<br />
class FOOBARPlugin : public ELFPlugin {<br />
public:<br />
FOOBARPlugin(const Common::String &filename) : ELFPlugin(filename) {}<br />
<br />
DLObject *makeDLObject() { return new FOOBARProcessorDLObject(); }<br />
};<br />
<br />
public:<br />
Plugin* createPlugin(const Common::FSNode &node) const {<br />
return new FOOBARPlugin(node.getPath());<br />
}<br />
};<br />
<br />
#endif // defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
</syntax><br />
<br />
==== Making the plugin linker script for your backend ====<br />
To generate this script, first find the linker script used to link a static build of the target platform (usually this is the default script for the linker, which you can dump via the command <tt>foobar-compiler-ld --verbose</tt>). You'll want to modify this linker in a few key ways.<br />
<br />
*First, you can remove the <tt>ENTRY(symbol)</tt> command. This command normally tells the linker which instruction should be the first to execute in the program, but since you're generating a plugin that will be linked in and jumped to from the main executable, it is not needed. <br />
*Next, define an ELF program header for a "plugin" segment to be loaded from the file. Do this by adding the following before the SECTIONS command:<br />
<syntax type="C++">PHDRS<br />
{<br />
plugin PT_LOAD ;<br />
}</syntax><br />
*Set the start address of the file to be 0 (since this will be linked in at a different address later), usually you can do this by replacing the first line in SECTIONS with <code>. = 0;</code>, though different ld scripts may require different modifications.<br />
*Place the first section (as listed under the SECTIONS command) into the "plugin" segment you defined in PHDRS by appending <tt>:plugin</tt> to the first sections-command, i.e <code>.text . : { *(.text) } :plugin</code>. As long as there aren't any other PHDRS, this should ensure the entire linked file is put in the "plugin" segment, since future sections assume they are to be put in the same segment as the previous section unless specified otherwise (via <tt>:phdr</tt> or <tt>:NONE</tt>).<br />
*Find the <tt>.ctors</tt> and <tt>.dtors</tt> sections (constructors and destructors) and delete any output-section-commands within them that reference crtbegin or crtend, i.e <code>KEEP (*crtbegin*.o(.dtors))</code> or <code>KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))</code>. Put <code>___plugin_ctors = .;</code> as the first output-section-command in the <tt>.ctors</tt> section and <code>___plugin_ctors_end = .;</code> as the last output-section-command. Do the same for the <tt>.dtors</tt> section but with <tt>___plugin_dtors</tt>, etc. This gives these symbols values that our run-time loader can use. In the end, <tt>.ctors</tt> and <tt>.dtors</tt> should look something like this:<br />
<syntax type="C++">.ctors :<br />
{<br />
___plugin_ctors = .;<br />
KEEP (*(SORT(.ctors.*)))<br />
KEEP (*(.ctors))<br />
___plugin_ctors_end = .;<br />
}<br />
.dtors :<br />
{<br />
___plugin_dtors = .;<br />
KEEP (*(SORT(.dtors.*)))<br />
KEEP (*(.dtors))<br />
___plugin_dtors_end = .;<br />
}</syntax><br />
*That's it! If you have trouble with any of these instructions or need to further modify the linker script for something specific to your platform, see [http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html] for linker script documentation and peruse the various <tt>plugin.ld</tt> files in the subdirectories of <tt>backends/plugins/</tt>. TODO: Add stuff about MIPS-specific linker script modifications, namely the "shorts" segment.<br />
<br />
==== Necessary Build Modifications ====<br />
There will undoubtedly be a number of things specific to your platform to deal with when it comes to modifying the building, but you should definitely add the following, bordered by #ifdef guards to make sure DYNAMIC_MODULES is set to 1 (along with telling the desired engines that you want them to be separate plugin files, i.e. "ENABLE_SCUMM = DYNAMIC_PLUGIN"):<br />
<br />
<syntax type="C++">DEFINES += ELF_LOADER_TARGET //also add any other necessary defines<br />
PLUGIN_SUFFIX := .plg //or whatever your suffix is<br />
PLUGIN_EXTRA_DEPS = $(EXECUTABLE)<br />
PLUGIN_LDFLAGS += -nostartfiles -Wl,-q,--just-symbols,$(EXECUTABLE),-T$(srcdir)/backends/plugins/foobar/plugin.ld,--retain-symbols-file,$(srcdir)/backends/plugins/plugin.syms<br />
PRE_OBJS_FLAGS := -Wl,--whole-archive<br />
POST_OBJS_FLAGS := -Wl,--no-whole-archive<br />
</syntax><br />
<br />
As you can see, these modifications mainly deal with making sure the plugins are dependent on the main executable and use the custom linker script.<br />
<br />
You will also need to make sure your main executable is not being overly stripped as the thing doing the stripping may think the executable doesn't use certain symbols simply because they reference portions of code that will be linked in later in a plugin.<br />
<br />
TODO: Add stuff about "ONE_PLUGIN_AT_A_TIME" once it is working perfectly.<br />
<br />
==== Subclassing DLObject ====<br />
At some point, the PluginManager will call <code>getPlugins()</code> on the FOOBARProvider, which will trigger a search for plugin files in your backend's file system and return a list of FOOBARPlugins based on the results of this search. The PluginManager will then be able to call <code>loadplugin()</code> and <code>unloadPlugin</code>, and on any of these FOOBARPlugins, which will involve calls to <code>open(const char *path)</code> on a new object that's a subclass of DLObject (which subclass is determined by how you coded <code>makeDLObject()</code> in the FOOBARPlugin class) with the path to the plugin file the FOOBARPlugin represents as its argument (The multiple levels of abstraction here can get confusing :-)). A subclass of DLObject, then, is ultimately responsible for opening the plugin files and loading them/unloading them from memory.<br />
<br />
TODO: Finish explaining what the DLObject class does and how to subclass it effectively.</div>Tonemanhttps://wiki.scummvm.org/index.php?title=HOWTO-Dynamic_Modules&diff=14438HOWTO-Dynamic Modules2010-08-16T00:30:24Z<p>Toneman: Added rough, initial HOWTO for implementing dynamic modules on a smaller target</p>
<hr />
<div>NOTE: many parts of this HOWTO assume the "gsoc2010-plugins" branch has been integrated into trunk.<br />
<br />
=== Introduction ===<br />
<br />
This page is meant as a mini-HOWTO which roughly outlines the steps needed to implement dynamic engine plugins for a previously unsupported backend (port) of ScummVM. This HOWTO only applies to targets that can use the ELF file-format and will generally only be useful for smaller targets that cannot support POSIX plugins. <br />
<br />
I will assume that you are at least roughly familiar with ScummVM, and have a fresh checkout of our Subversion repository. Note that it's strongly advised to base your work on the current development version of ScummVM, and not on a release version. This will ease integration of your work.<br />
<br />
=== Overview ===<br />
<br />
ScummVM has a PluginManager class that potentially keeps track of multiple plugin providers. As of this writing, a StaticPluginProvider is always added to this PluginManager that keeps track of all statically-linked plugins. Your job will be to add a dynamic plugin provider specific to the backend you're working on that will provide for any dynamic plugins that are enabled on that backend and to tell the backend to use this provider in the case that dynamic modules are enabled.<br />
<br />
=== Step by step ===<br />
<br />
For the rest of this document, I will assume you are attempting to implement loadable modules for the "foobar" port of ScummVM :-).<br />
<br />
# Create a new <code>backends/plugins</code> subdirectory matching the name of the port you're providing for, i.e. <tt>backends/plugins/foobar/</tt>.<br />
# Create a provider file in this subdirectory, such as <tt>foobar-provider.h</tt> that contains the class declaration of the provider for your port. This class should subtype ELFPluginProvider. This class should nest a class declaration that subtypes ELFPlugin but is specific to your port (i.e. <tt>FOOBARPlugin</tt>) and override ELFPluginProvider's "createPlugin" method with its own that returns a new FOOBARPlugin object (See example below).<br />
# The FOOBARPlugin class needs to override ELFPlugin's "makeDLObject" method and have it return a new object of an appropriate subclass of DLObject. Currently, the subclasses of DLObject are processor-specific, but depending on the port, you may find you have to subclass one of these processor-specific subclasses with a platform-specific one, such as <tt>FOOBARDLObject()</tt>. (See "Subclassing DLObject" below).<br />
# Find where <code>scummvm_main(argc, argv)</code> is invoked in your backend's main and somewhere shortly before it add the FOOBARPluginProvider to the PluginManager, i.e. <code>PluginManager::instance().addPluginProvider(new FOOBARPluginProvider();</code> (Be sure to guard this call with <code>#ifdef DYNAMIC_MODULES</code>). This, of course, will require that you include the FOOBARPluginProvider header at the top of the file.<br />
# Now we need to get the backend generating custom engine plugin files that can be loaded/unloaded to/from memory at will during runtime. To make the runtime linking (loading) of plugin files easier to handle, we let ld do some of the work for us at compile-time. First, we build the non-relocatable main executable <tt>scummvm.elf</tt> (Manually implementing Dynamic Modules on a smaller target that doesn't allow the main executable to be non-relocatable has not yet been successfully done and, as such, is not covered by this HOWTO). Then we link the plugins files together with a custom ld linker script; ld uses the absolute addresses from the main executable to resolve messy jumps from the plugin back to the main code and thus does much of the more complicated dynamic work for us. I would suggest adding the necessary custom linker script into the <tt>backends/plugins/foobar/</tt> directory you made earlier (See "Making the plugin linker script for your backend" below).<br />
# Modify the build system for your backend (See "Necessary Build Modifications" below).<br />
# Cross your fingers and be prepared to work at things for a while if it doesn't immediately function ;-)<br />
<br />
==== Example of foobar-provider.h====<br />
<syntax type="C++">#if defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
<br />
#include "backends/plugins/elf-provider.h"<br />
#include "backends/plugins/foobarprocessor-loader.h"<br />
<br />
class FOOBARPluginProvider : public ELFPluginProvider {<br />
class FOOBARPlugin : public ELFPlugin {<br />
public:<br />
FOOBARPlugin(const Common::String &filename) : ELFPlugin(filename) {}<br />
<br />
DLObject *makeDLObject() { return new FOOBARProcessorDLObject(); }<br />
};<br />
<br />
public:<br />
Plugin* createPlugin(const Common::FSNode &node) const {<br />
return new FOOBARPlugin(node.getPath());<br />
}<br />
};<br />
<br />
#endif // defined(DYNAMIC_MODULES) && defined(FOOBAR)<br />
</syntax><br />
<br />
==== Making the plugin linker script for your backend ====<br />
To generate this script, first find the linker script used to link a static build of the target platform (usually this is the default script for the linker, which you can dump via the command <tt>foobar-compiler-ld --verbose</tt>).<br />
<br />
TODO: Fill out this section.<br />
<br />
==== Necessary Build Modifications ====<br />
There will undoubtedly be a number of things specific to your platform to deal with when it comes to modifying the building, but you should definitely add the following, bordered by #ifdef guards to make sure DYNAMIC_MODULES is set to 1 (along with telling the desired engines that you want them to be separate plugin files, i.e. "ENABLE_SCUMM = DYNAMIC_PLUGIN"):<br />
<br />
<syntax type="C++">DEFINES += ELF_LOADER_TARGET //also add any other necessary defines<br />
PLUGIN_SUFFIX := .plg //or whatever your suffix is<br />
PLUGIN_EXTRA_DEPS = $(EXECUTABLE)<br />
PLUGIN_LDFLAGS += -nostartfiles -Wl,-q,--just-symbols,$(EXECUTABLE),-T$(srcdir)/backends/plugins/foobar/plugin.ld,--retain-symbols-file,$(srcdir)/backends/plugins/plugin.syms<br />
PRE_OBJS_FLAGS := -Wl,--whole-archive<br />
POST_OBJS_FLAGS := -Wl,--no-whole-archive<br />
</syntax><br />
<br />
As you can see, these modifications mainly deal with making sure the plugins are dependent on the main executable and use the custom linker script.<br />
<br />
You will also need to make sure your main executable is not being overly stripped as the thing doing the stripping may think the executable doesn't use certain symbols simply because they reference portions of code that will be linked in later in a plugin.<br />
<br />
TODO: Add stuff about "ONE_PLUGIN_AT_A_TIME" once it is working perfectly.<br />
<br />
==== Subclassing DLObject ====<br />
At some point, the PluginManager will call <code>getPlugins()</code> on the FOOBARProvider, which will trigger a search for plugin files in your backend's file system and return a list of FOOBARPlugins based on the results of this search. The PluginManager will then be able to call <code>loadplugin()</code> and <code>unloadPlugin</code>, and on any of these FOOBARPlugins, which will involve calls to <code>open(const char *path)</code> on a new object that's a subclass of DLObject (which subclass is determined by how you coded <code>makeDLObject()</code> in the FOOBARPlugin class) with the path to the plugin file the FOOBARPlugin represents as its argument (The multiple levels of abstraction here can get confusing :-)). A subclass of DLObject, then, is ultimately responsible for opening the plugin files and loading them/unloading them from memory.<br />
<br />
TODO: Finish explaining what the DLObject class does and how to subclass it effectively.</div>Tonemanhttps://wiki.scummvm.org/index.php?title=How_to_guides&diff=14437How to guides2010-08-16T00:20:06Z<p>Toneman: /* HOW-TOs */</p>
<hr />
<div>===Documentation===<br />
<br />
* A list of [[Datafiles|datafiles]] needed to run games i<br />
n ScummVM.<br />
* The [[User Manual]]. It is incomplete and '''we need your help to finish it!''' For details, go to the [[User Manual]] page!<br />
* Information for [[Compiling ScummVM]] yourself.<br />
* A list of [[International Game Titles]].<br />
* A list of the [[Boot Params]] of some games.<br />
* [[Copyright FAQ]] explains our hard stance on copying game data without buying it, abandonware, warez and similar things.<br />
* A guide on submitting [[Screenshots]] for use on our website.<br />
<br />
===HOW-TOs===<br />
<br />
* HOWTO extract/copy Mac Games to use with ScummVM [[HOWTO-Mac_Games |Mac Games HOWTO]]<br />
* HOWTO extract the Loom PC-Engine/TG16 data track to use with ScummVM [[HOWTO-LoomTG16 |LoomTG16 HOWTO]]<br />
* HOWTO create a FM-Towns font rom(FMT_FNT.ROM) using a Windows font [[HOWTO-FMT_FNT |FM-Towns Font Rom HOWTO]]<br />
* HOWTO translate the ScummVM GUI [[HOWTO-Translate_ScummVM_GUI |Translation HOWTO]]<br />
* HOWTO implement loadable modules on a smaller backend where dynamic plugins were previously unsupported [[HOWTO-Dynamic_Modules |Dynamic Modules HOWTO]]</div>Tonemanhttps://wiki.scummvm.org/index.php?title=How_to_guides&diff=14436How to guides2010-08-16T00:18:24Z<p>Toneman: Added Dynamic Modules HOWTO</p>
<hr />
<div>===Documentation===<br />
<br />
* A list of [[Datafiles|datafiles]] needed to run games i<br />
n ScummVM.<br />
* The [[User Manual]]. It is incomplete and '''we need your help to finish it!''' For details, go to the [[User Manual]] page!<br />
* Information for [[Compiling ScummVM]] yourself.<br />
* A list of [[International Game Titles]].<br />
* A list of the [[Boot Params]] of some games.<br />
* [[Copyright FAQ]] explains our hard stance on copying game data without buying it, abandonware, warez and similar things.<br />
* A guide on submitting [[Screenshots]] for use on our website.<br />
<br />
===HOW-TOs===<br />
<br />
* HOWTO extract/copy Mac Games to use with ScummVM [[HOWTO-Mac_Games |Mac Games HOWTO]]<br />
* HOWTO extract the Loom PC-Engine/TG16 data track to use with ScummVM [[HOWTO-LoomTG16 |LoomTG16 HOWTO]]<br />
* HOWTO create a FM-Towns font rom(FMT_FNT.ROM) using a Windows font [[HOWTO-FMT_FNT |FM-Towns Font Rom HOWTO]]<br />
* HOWTO translate the ScummVM GUI [[HOWTO-Translate_ScummVM_GUI |Translation HOWTO]]<br />
* HOWTO implement loadable modules on a backend where dynamic plugins were previously unsupported [[HOWTO-Dynamic_Modules |Dynamic Modules HOWTO]]</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=14408User:Toneman2010-08-07T18:24:44Z<p>Toneman: </p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
<strike>May 24th - June 13th: Do the task!</strike><br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
<strike>June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).</strike><br />
<br />
<strike>June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.</strike><br />
<br />
<strike>June 28th - July 2nd: Discussed Wiz problems and made final design decisions concerning plugin loading with mentors, abandoning Wiz as a testbed for now.</strike> ([http://tonypuccinelli.blogspot.com/2010/06/restructuring.html http://tonypuccinelli.blogspot.com/2010/06/restructuring.html])<br />
<br />
<br />
====Implement support for loadable modules on the DS. (To be completed by: July 16th)====<br />
<br />
<strike>July 5th-9th: Get Debugging Facilities Set up for the DS, completely code module loader for DS.</strike><br />
<br />
<strike>July 12th-21st: Debug and test DS (only building one or two plugins) until the module loader is in a usable state.</strike><br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: August 6th)====<br />
<br />
<strike>July 22nd-25th: Do the task!</strike><br />
<br />
<br />
====Change Plugin Design (To be completed by: July 30th)====<br />
<br />
July 26th-30th: Begin Plugin Design Change Work. Complete "First Refinement" and Begin on "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
August 2nd-6th: Complete "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
<br />
====End of Summmer====<br />
<br />
August 9th-13th: Code Reintegration Phase/Wiggle Room :-)<br />
<br />
August 14th-???: Continue work with ScummVM? ;-)<br />
<br />
<br />
<br />
==Plugin Design Change Plans (Subject to Change)==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=14114User:Toneman2010-07-23T00:32:22Z<p>Toneman: </p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
<strike>May 24th - June 13th: Do the task!</strike><br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
<strike>June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).</strike><br />
<br />
<strike>June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.</strike><br />
<br />
<strike>June 28th - July 2nd: Discussed Wiz problems and made final design decisions concerning plugin loading with mentors, abandoning Wiz as a testbed for now.</strike> ([http://tonypuccinelli.blogspot.com/2010/06/restructuring.html http://tonypuccinelli.blogspot.com/2010/06/restructuring.html])<br />
<br />
<br />
====Implement support for loadable modules on the DS. (To be completed by: July 16th)====<br />
<br />
<strike>July 5th-9th: Get Debugging Facilities Set up for the DS, completely code module loader for DS.</strike><br />
<br />
<strike>July 12th-21st: Debug and test DS (only building one or two plugins) until the module loader is in a usable state.</strike><br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: August 6th)====<br />
<br />
July 22nd-25th: Do the task!<br />
<br />
<br />
====Change Plugin Design (To be completed by: July 30th)====<br />
<br />
July 26th-30th: Begin Plugin Design Change Work. Complete "First Refinement" and Begin on "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
August 2nd-6th: Complete "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
<br />
====End of Summmer====<br />
<br />
August 9th-13th: Code Reintegration Phase/Wiggle Room :-)<br />
<br />
August 14th-???: Continue work with ScummVM? ;-)<br />
<br />
<br />
<br />
==Plugin Design Change Plans (Subject to Change)==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=14098User:Toneman2010-07-20T22:21:35Z<p>Toneman: </p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
<strike>May 24th - June 13th: Do the task!</strike><br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
<strike>June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).</strike><br />
<br />
<strike>June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.</strike><br />
<br />
<strike>June 28th - July 2nd: Discussed Wiz problems and made final design decisions concerning plugin loading with mentors, abandoning Wiz as a testbed for now.</strike> ([http://tonypuccinelli.blogspot.com/2010/06/restructuring.html http://tonypuccinelli.blogspot.com/2010/06/restructuring.html])<br />
<br />
<br />
====Implement support for loadable modules on the DS. (To be completed by: July 16th)====<br />
<br />
<strike>July 5th-9th: Get Debugging Facilities Set up for the DS, completely code module loader for DS.</strike><br />
<br />
July 12th-21st: Debug and test DS (only building one or two plugins) until the module loader is in a usable state.<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: August 6th)====<br />
<br />
July 22nd-25th: Do the task!<br />
<br />
<br />
====Change Plugin Design (To be completed by: July 30th)====<br />
<br />
July 26th-30th: Begin Plugin Design Change Work. Complete "First Refinement" and Begin on "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
August 2nd-6th: Complete "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
<br />
====End of Summmer====<br />
<br />
August 9th-13th: Code Reintegration Phase/Wiggle Room :-)<br />
<br />
August 14th-???: Continue work with ScummVM? ;-)<br />
<br />
<br />
<br />
==Plugin Design Change Plans (Subject to Change)==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=14097User:Toneman2010-07-20T22:20:37Z<p>Toneman: </p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
<strike>May 24th - June 13th: Do the task!</strike><br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
<strike>June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).</strike><br />
<br />
<strike>June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.</strike><br />
<br />
<strike>June 28th - July 2nd: Discussed Wiz problems and made final design decisions concerning plugin loading with mentors, abandoning Wiz as a testbed for now.</strike> ([http://tonypuccinelli.blogspot.com/2010/06/restructuring.html http://tonypuccinelli.blogspot.com/2010/06/restructuring.html])<br />
<br />
<br />
====Implement support for loadable modules on the DS. (To be completed by: July 16th)====<br />
<br />
<strike>July 5th-9th: Get Debugging Facilities Set up for the DS, completely code module loader for DS.</strike><br />
<br />
July 12th-21st: Debug and test DS (only building one or two plugins) until the module loader is in a usable state.<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: August 6th)====<br />
<br />
July 22nd-25th: Do the task!<br />
<br />
<br />
====Change Plugin Design (To be completed by: July 30th)====<br />
<br />
July 26th-30th: Begin Plugin Design Change Work. Complete "First Refinement" and Begin on "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
August 2nd-6th: Complete "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
====End of Summmer====<br />
<br />
August 9th-13th: Code Reintegration Phase/Wiggle Room :-)<br />
<br />
August 14th-???: Continue work with ScummVM? ;-)<br />
<br />
<br />
<br />
==Plugin Design Change Plans (Subject to Change)==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=14096User:Toneman2010-07-20T22:18:11Z<p>Toneman: rearranged schedule and added code reintegration to it</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
Completed on June 13th!<br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
<strike>June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).</strike><br />
<br />
<strike>June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.</strike><br />
<br />
<strike>June 28th - July 2nd: Discussed Wiz problems and made final design decisions concerning plugin loading with mentors, abandoning Wiz as a testbed for now.</strike> ([http://tonypuccinelli.blogspot.com/2010/06/restructuring.html http://tonypuccinelli.blogspot.com/2010/06/restructuring.html])<br />
<br />
<br />
====Implement support for loadable modules on the DS. (To be completed by: July 16th)====<br />
<br />
<strike>July 5th-9th: Get Debugging Facilities Set up for the DS, completely code module loader for DS.</strike><br />
<br />
July 12th-21st: Debug and test DS (only building one or two plugins) until the module loader is in a usable state.<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: August 6th)====<br />
<br />
July 22nd-25th: Do the task!<br />
<br />
<br />
====Change Plugin Design (To be completed by: July 30th)====<br />
<br />
July 26th-30th: Begin Plugin Design Change Work. Complete "First Refinement" and Begin on "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
August 2nd-6th: Complete "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
====End of Summmer====<br />
<br />
August 9th-13th: Code Reintegration Phase/Wiggle Room :-)<br />
<br />
August 14th-???: Continue work with ScummVM? ;-)<br />
<br />
<br />
<br />
==Plugin Design Change Plans (Subject to Change)==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=14013User:Toneman2010-07-02T20:44:25Z<p>Toneman: </p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
Completed on June 13th!<br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
<strike>June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).</strike><br />
<br />
<strike>June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.</strike><br />
<br />
<strike>June 28th - July 2nd: Discussed Wiz problems and made final design decisions concerning plugin loading with mentors, abandoning Wiz as a testbed for now.</strike> ([http://tonypuccinelli.blogspot.com/2010/06/restructuring.html http://tonypuccinelli.blogspot.com/2010/06/restructuring.html])<br />
<br />
<br />
====Implement support for loadable modules on the DS. (To be completed by: July 16th)====<br />
<br />
July 5th-9th: Get Debugging Facilities Set up for the DS, completely code module loader for DS.<br />
<br />
July 12th-16th: Debug and test DS (only building one or two plugins) until the module loader is in a usable state.<br />
<br />
<br />
====Change Plugin Design (To be completed by: July 30th)====<br />
<br />
July 19th-23rd: Begin Plugin Design Change Work. Complete "First Refinement" and Begin on "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
July 26th-30th: Complete "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: August 6th)====<br />
<br />
August 2nd-6th: Do the task!<br />
<br />
<br />
====End of Summmer====<br />
<br />
August 9th-13th: Wiggle Room for finishing GSOC :-)<br />
<br />
August 14th-???: Continue work with ScummVM? ;-)<br />
<br />
<br />
<br />
==Plugin Design Change Plans (Subject to Change)==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=14012User:Toneman2010-07-02T20:43:42Z<p>Toneman: Modified Schedule</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
Completed on June 13th!<br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
<strike>June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).</strike><br />
<br />
<strike>June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.</strike><br />
<br />
<strike>June 28th - July 2nd: Discussed Wiz problems and made final design decisions concerning plugin loading with mentors, abandoning Wiz as a testbed for now.</strike> ([http://tonypuccinelli.blogspot.com/2010/06/restructuring.html http://tonypuccinelli.blogspot.com/2010/06/restructuring.html])<br />
<br />
====Implement support for loadable modules on the DS. (To be completed by: July 16th)====<br />
<br />
July 5th-9th: Get Debugging Facilities Set up for the DS, completely code module loader for DS.<br />
<br />
July 12th-16th: Debug and test DS (only building one or two plugins) until the module loader is in a usable state.<br />
<br />
====Change Plugin Design (To be completed by: July 30th)====<br />
<br />
July 19th-23rd: Begin Plugin Design Change Work. Complete "First Refinement" and Begin on "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
July 26th-30th: Complete "Long Term Approach" (see "Plugin Design Change Plans" below).<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: August 6th)====<br />
<br />
August 2nd-6th: Do the task!<br />
<br />
====End of Summmer====<br />
<br />
August 9th-13th: Wiggle Room for finishing GSOC :-)<br />
<br />
August 14th-???: Continue work with ScummVM? ;-)<br />
<br />
==Plugin Design Change Plans (Subject to Change)==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13943User:Toneman2010-06-25T06:48:45Z<p>Toneman: </p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
Completed on June 13th!<br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).<br />
<br />
June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.<br />
<br />
June 28th - July 2nd: Continue work on the GP2x Wiz.<br />
<br />
July 5th - July 9th: Finish ELF loader for the Wiz.<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: July 16th)====<br />
<br />
July 12th-16th: Do the task!<br />
<br />
<br />
====Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code. (To be completed by: August 13th)====<br />
<br />
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).<br />
<br />
July 26th-30th: Begin making necessary changes to GP2x loader/linker to adapt it for DS and altered design.<br />
<br />
August 2nd-6th: Continue work on the DS.<br />
<br />
August 9th-13th: Finish coding!<br />
<br />
<br />
====Continue work with ScummVM? ;-)====<br />
<br />
<br />
==Plugin Design Change Plans (Subject to Change)==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13942User:Toneman2010-06-25T00:25:54Z<p>Toneman: added "extra concerns" to Plugin Design Change Plans</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
Completed on June 13th!<br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).<br />
<br />
June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.<br />
<br />
June 28th - July 2nd: Continue work on the GP2x Wiz.<br />
<br />
July 5th - July 9th: Finish ELF loader for the Wiz.<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: July 16th)====<br />
<br />
July 12th-16th: Do the task!<br />
<br />
<br />
====Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code. (To be completed by: August 13th)====<br />
<br />
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).<br />
<br />
July 26th-30th: Begin making necessary changes to GP2x loader/linker to adapt it for DS and altered design.<br />
<br />
August 2nd-6th: Continue work on the DS.<br />
<br />
August 9th-13th: Finish coding!<br />
<br />
<br />
====Continue work with ScummVM? ;-)====<br />
<br />
<br />
==Plugin Design Change Plans==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.<br />
<br />
<br />
3) Extra Concerns<br />
-------------------------------<br />
<br />
*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.<br />
<br />
*To support "--list-games", we can just load every engine individually and add the output to a list.<br />
<br />
*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 :-).</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13941User:Toneman2010-06-24T23:49:56Z<p>Toneman: Modified Plugin Design Change Plans</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
Completed on June 13th!<br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).<br />
<br />
June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.<br />
<br />
June 28th - July 2nd: Continue work on the GP2x Wiz.<br />
<br />
July 5th - July 9th: Finish ELF loader for the Wiz.<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: July 16th)====<br />
<br />
July 12th-16th: Do the task!<br />
<br />
<br />
====Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code. (To be completed by: August 13th)====<br />
<br />
July 19th-23rd: Get Debugging Facilities Set up for the DS and make final design decisions with mentors (see "Plugin Design Change Plans" below).<br />
<br />
July 26th-30th: Begin making necessary changes to GP2x loader/linker to adapt it for DS and altered design.<br />
<br />
August 2nd-6th: Continue work on the DS.<br />
<br />
August 9th-13th: Finish coding!<br />
<br />
<br />
====Continue work with ScummVM? ;-)====<br />
<br />
<br />
==Plugin Design Change Plans==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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.</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13940User:Toneman2010-06-24T23:39:56Z<p>Toneman: Added Plugin Design Change Stuff</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
Completed on June 13th!<br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).<br />
<br />
June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.<br />
<br />
June 28th - July 2nd: Continue work on the GP2x Wiz.<br />
<br />
July 5th - July 9th: Finish ELF loader for the Wiz.<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: July 16th)====<br />
<br />
July 12th-16th: Do the task!<br />
<br />
<br />
====Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code. (To be completed by: August 13th)====<br />
<br />
July 19th-23rd: Get Debugging Facilities Set up for the DS and make final design decisions with mentors (see "Plugin Design Change Plans" below).<br />
<br />
July 26th-30th: Begin making necessary changes to GP2x loader/linker to adapt it for DS and altered design.<br />
<br />
August 2nd-6th: Continue work on the DS.<br />
<br />
August 9th-13th: Finish coding!<br />
<br />
<br />
====Continue work with ScummVM? ;-)====<br />
<br />
<br />
==Plugin Design Change Plans==<br />
<br />
1) First Refinement<br />
------------------------------<br />
<br />
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.<br />
<br />
<br />
2) Long Term Approach<br />
-------------------------------<br />
<br />
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".<br />
<br />
Also, the upgradeTargets() function in base/commandLine.cpp could be modified such that during startup, any config targets missing the "engine" key could have an "engine" key added automatically (by re-running the detector, matching the output with the gameid that is already there, and setting up the engine field).<br />
<br />
In order to avoid having to do this re-scanning every time, we could put the "version" field in the config file to use. We could change it so that if we are loading a config file made with a newer ScummVM version, a warning is issued, and if the version is older than XYZ, we run the target upgrader.</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13874User:Toneman2010-06-14T19:26:14Z<p>Toneman: Explicit Dates added to schedule</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
====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.====<br />
<br />
Completed on June 13th!<br />
<br />
<br />
====Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)====<br />
<br />
June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).<br />
<br />
June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.<br />
<br />
June 28th - July 2nd: Continue work on the GP2x Wiz.<br />
<br />
July 5th - July 9th: Finish ELF loader for the Wiz.<br />
<br />
<br />
====Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: July 16th)====<br />
<br />
July 12th-16th: Do the task!<br />
<br />
<br />
====Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code. (To be completed by: August 13th)====<br />
<br />
July 19th-23rd: Get Debugging Facilities Set up for the DS and make design decisions with mentors (for instance, only one engine can be loaded at a time instead of all loaded then unneeded ones deleted).<br />
<br />
July 26th-30th: Begin making necessary changes to GP2x loader/linker to adapt it for DS and altered design.<br />
<br />
August 2nd-6th: Continue work on the DS.<br />
<br />
August 9th-13th: Finish coding!<br />
<br />
<br />
====Continue work with ScummVM? ;-)====</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13873User:Toneman2010-06-14T04:12:15Z<p>Toneman: altered schedule</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
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.<br />
<br />
Completed on June 13th!<br />
<br />
<br />
Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)<br />
First Week Goal: Get debugging facilities set up for the GP2x. Get initial linker scripts/loader coded. (Continue testing/documenting PS2 work).<br />
Second Week Goal: Tweak Makefile and begin debugging.<br />
Third Week Goal: Continue work on the GP2x Wiz.<br />
Fourth Week Goal: Finish ELF loader for the Wiz.<br />
<br />
<br />
Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: July 16th)<br />
<br />
<br />
Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code. (To be completed by: August 13th)<br />
First Week Goal: Get Debugging Facilities Set up for the DS and make design decisions with mentors (for instance, only one engine can be loaded at a time instead of all loaded then unneeded ones deleted).<br />
Second Week Goal: Begin making necessary changes to GP2x loader/linker to adapt it for DS and altered design.<br />
Third Week Goal: Continue work on the DS.<br />
Fourth Week Goal: Finish coding!<br />
<br />
Continue work with ScummVM? ;-)</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13866User:Toneman2010-06-11T17:49:01Z<p>Toneman: slightly modifying schedule</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
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.<br />
<br />
To be completed by: June 16th<br />
<br />
<br />
Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules.<br />
<br />
To be completed by: June 23rd<br />
<br />
<br />
Implement support for loadable modules on the GP2x, an ARM target.<br />
<br />
To be completed by: July 19th<br />
<br />
<br />
Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code.<br />
<br />
To be completed by: August 9th</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13859User:Toneman2010-06-09T01:55:58Z<p>Toneman: Project Schedule Added</p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]<br />
<br />
== Current Project Schedule ==<br />
<br />
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.<br />
<br />
To be completed by: June 11th<br />
<br />
<br />
Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules.<br />
<br />
To be completed by: June 21st<br />
<br />
<br />
Implement support for loadable modules on the GP2x, an ARM target.<br />
<br />
To be completed by: July 19th<br />
<br />
<br />
Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code.<br />
<br />
To be completed by: August 9th</div>Tonemanhttps://wiki.scummvm.org/index.php?title=Compiling_ScummVM/PlayStation_2&diff=13824Compiling ScummVM/PlayStation 22010-05-30T22:51:15Z<p>Toneman: Filled out the wiki page with real contents</p>
<hr />
<div>= a. Decide were your tools and your sdk are going to be ;-) =<br />
<br />
For example:<br />
/works/devel/ps2/tools<br />
/works/devel/ps2/sdk<br />
<br />
= b. First we need the tools, let's get them started with svn... =<br />
<br />
<syntaxhighlight type="bash">svn co svn://svn.ps2dev.org/ps2/trunk/ps2toolchain</syntaxhighlight><br />
<br />
= c. ...and build them using toolchain.sh! =<br />
<br />
Make sure that you have the correct env settings<br />
<br />
For me:<br />
<br />
export PS2DEV=/works/devel/ps2/tools<br />
export PATH=$PATH:$PS2DEV/bin<br />
export PATH=$PATH:$PS2DEV/ee/bin<br />
export PATH=$PATH:$PS2DEV/iop/bin<br />
export PATH=$PATH:$PS2DEV/dvp/bin<br />
export PS2SDK=/works/devel/ps2/sdk<br />
export PATH=$PATH:$PS2SDK/bin<br />
<br />
You will need them in the future too (not only to create<br />
the tools) so you might want to add them to your profile.<br />
<br />
Note:<br />
the script will download the needed sources from the net.<br />
As of right now, the ps2 port won't compile with the most<br />
recent versions of the toolchain so you will have to modify<br />
the scripts "005-ps2sdk.sh" and "006-ps2client.sh" to svn check<br />
out revision 1628 or earlier.<br />
<br />
You won't need most of "ps2toolchain" after building but be sure to<br />
save the ps2sdk source (from ps2toolchain/build/ps2sdk) because some<br />
other libs (eg. SjPcm) rely on it.<br />
I suggest keeping it in /works/devel/ps2/sdk and export:<br />
<br />
<syntaxhighlight type="bash">export PS2SDKSRC=/works/devel/ps2/sdk-src</syntaxhighlight><br />
<br />
= d. Nearly there! Now we still need some extra libs which are not provided with default SDK: =<br />
<br />
- I suggest storing all of them in "sdk-extra" so that you just need to edit one line in Makefile.ps2 to compile scummvm<br />
<br />
- you can call it "sdk-ports" if you want to be consistent with svn naming structures<br />
<br />
// zlib<br />
svn co svn://svn.ps2dev.org/ps2/trunk/ps2sdk-ports/zlib<br />
cd zlib<br />
make<br />
<br />
// libmad<br />
svn co svn://svn.ps2dev.org/ps2/trunk/ps2sdk-ports/libmad<br />
cd libmad<br />
mkdir ee/lib<br />
make<br />
<br />
// sjcpm & tremor<br />
[ the porter will have to provide these as they are specially optimized versions for the PS2<br />
You can contact him at sunmax@libero.it]<br />
<br />
<br />
= e. get scummvm =<br />
<br />
<syntaxhighlight type="bash">svn co https://scummvm.svn.sourceforge.net/svnroot/scummvm/scummvm/trunk trunk</syntaxhighlight><br />
<br />
-or-<br />
<br />
<syntaxhighlight type="bash">svn co https://scummvm.svn.sourceforge.net/svnroot/scummvm/scummvm/branches/branch-1-0-0</syntaxhighlight><br />
<br />
<syntaxhighlight type="bash">cd trunk/backends/platform/ps2</syntaxhighlight><br />
<br />
edit Makefile.ps2 to match your sdk-extra (for example: PS2_EXTRA = /works/devel/ps2/sdk-extra)<br />
<br />
<syntaxhighlight type="bash">make -f Makefile.ps2</syntaxhighlight><br />
<br />
Your fresh-baked scummvm will be waiting for you in elf/scummvm.elf ;-)<br />
If you don't need the symbols, just strip them ee-strip --strip-all scummvm.elf<br />
<br />
<br />
'''enjoy!'''</div>Tonemanhttps://wiki.scummvm.org/index.php?title=Summer_of_Code/GSoC2010&diff=13746Summer of Code/GSoC20102010-05-21T05:53:32Z<p>Toneman: </p>
<hr />
<div>== Introduction ==<br />
<br />
This pages lists students and projects for the [http://socghop.appspot.com/gsoc/program/home/google/gsoc2010 Google Summer of Code 2010]. See also Google's [http://socghop.appspot.com/gsoc/org/home/google/gsoc2010/scummvm ScummVM organization info] page.<br />
<br />
== Adding a testing framework for ScummVM's subsystems ==<br />
;Student: Neeraj Kumar<br />
;Mentors: [[User:Sev|Eugene Sandulenko]], [[User:Jvprat|Jordi Vialta Prat]]<br />
<br />
<br />
== Implementing support for Loadable Modules on MIPS and ARM-based platforms ==<br />
;Student: [[User:Toneman|Anthony Puccinelli]]<br />
;Mentors: [[User:Bluddy|Yotam Barnoy]], [[User:DJWillis|John Willis]]<br />
<br />
<br />
== Refactoring of the SDL backend and OpenGL support ==<br />
;Student: [[User:Vgvgf|Alejandro Marzini]]<br />
;Mentors: [[User:JoostP|Joost Peters]], [[User:Jvprat|Jordi Vialta Prat]], [[User:DJWillis|John Willis]]<br />
<br />
== Game script (bytecode) decompiler ==<br />
;Student: [[User:Pidgeot|Michael Madsen]]<br />
;Mentors: [[User:LordHoto|Johannes Schickel]], [[User:Fingolfin|Max Horn]]<br />
<br />
__NOTOC__</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13745User:Toneman2010-05-21T05:51:58Z<p>Toneman: </p>
<hr />
<div>{{User|<br />
handle=Toneman|<br />
name=Tony Puccinelli|<br />
memberSince=20/05/2010|<br />
workingOn=[[OpenTasks#Implemented_support_for_loadable_modules_on_small_devices|Implemented Support for Loadable Modules on Small Devices]]|<br />
blog=[http://tonypuccinelli.blogspot.com http://tonypuccinelli.blogspot.com]|<br />
email=tony.puccinelli@gmail.com<br />
}}<br />
<br />
== About Me ==<br />
<br />
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://tonypuccinelli.blogspot.com Pearls on a String]</div>Tonemanhttps://wiki.scummvm.org/index.php?title=User:Toneman&diff=13744User:Toneman2010-05-21T05:27:00Z<p>Toneman: Created page with '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 lo…'</p>
<hr />
<div>I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.<br />
<br />
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".<br />
<br />
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: [http://www.example.com Pearls on a String]</div>Toneman