Hey all!
It’s been a while since I last blogged (whoops!).
But in the time since my last post, quite a bit has happened.
First off, I got the DS port working with loadable modules after reintegrating the thumb-interworking code into the DS port. It was quite simple, really, as the thumb relocations used were PC-relative (and thus needed little to no manual work). I tested a good number of the engines after getting this work done, including the SCUMM, SKY, LURE, QUEEN, and AGI engines. They all seemed to work fine (though I only played through about 10 minutes of each game and I’ve heard some, like Sam and Max, use more memory later on). The one exception in terms of successful testing is the CRUISE engine. That plugin had a single relocation type (R_ARM_TARGET1) that none of the other engines have. This type is supposed to be treated either the same as R_ARM_ABS32 or R_ARM_REL32 (how it should be treated can differ, even in the same file). Since I saw no easy way to determine how it should be treated during runtime, I added “–target1-abs” linker flags to the ds makefile (the flags specify that R_ARM_TARGET1 should be treated as R_ARM_ABS32 in all cases) and coded for the R_ARM_TARGET1 relocation accordingly, but to no avail (“Cruise for a Corpse” still crashes on bootup, showing only the Cruise cursor). As of now I can’t see the console (on the top screen of the ds) at the point of the crash, so debugging is difficult, but I’ll continue to work on this.
Another problem with the DS build is that (as mentioned before) I had to remove the “–gc-sections” linker flags since things were being garbage-collected in the plugins and main executable that referred to each other. This unfortunately resulted in a lot of bloat in the main executable. For some engines, this bloat is around 300kb, which is too much to be ignored. There’s been some discussion among the mentors concerning different ways to decrease this bloat, including building static builds with garbage collection and dumping the symbols then telling the linker to included only those symbols in the dynamic builds. In any case, this is something that will need to be worked on before the DS dynamic plugins work is reintegrated into the trunk.
Apart from the DS work, I did some work abstracting a more generic ELF-loader last week. It’s a little rough at the moment, but works for both the PS2 and DS ports, so at least I didn’t break anything :-). I put the methods dealing with relocations into their own files based on processor type (like arm-relocs.cpp and mips-relocs.cpp) and also split the shorts-segment-manager (made to effectively use the gp-relative section of MIPS processors) into its own file. There’s still a bit of work to be done for abstraction, including making subclasses of DLObject (like PS2DLObject, which could be a subclass of MIPSDLObject, etc.) and having the different plugin-providers use these different subclasses (right now, I just used “ifdefs” with different ports).
I’ve also worked on a bit of the plugin design change work. It took me a while of looking through the base code to understand how to best begin implementing the plugin design changes, but I added some new functions to the PluginManager class (a “loadFirstPlugin” and “loadNextPlugin”) as well as changing main.cpp and some functions in plugins.cpp to use these functions in a loop when “NEW_PLUGIN_DESIGN_FIRST_REFINEMENT” is enabled. I tested on a Windows build with dynamic plugins enabled and was able to successfully launch games with only one plugin ever loaded at a time!
So the plan for this week is to continue plugin design change, abstraction, Cruise for a Corpse, and DS memory problem work,
Tony