Why It's Fun: World of Goo

The age of digitally-distributed media is upon us (I mean just look at this life-changing announcement!) and in the world of videogames this has most definitely been a good thing.

"Why?" you ask, sweat beading on your forehead in clamorous anticipation...

Because, sirs and madams, it has given startup indie game developers the means to distribute (and thus, the motive to create) games with fresh ideas that stand as beacons of hope in a monotonous minefield of first-person-shooters that have you trudging through monotonous minefields.

Case in point: World of Goo

World of Goo is a very strange game that has you building squishy, truss-like structures out of eager and eccentric goo-balls to reach up and up and up...

The game is fun because it taps into that child-like sense of discovery you first satiated in a sandbox during recess, learning through trial-and-error that the world has rules and that you can exploit them to create freakin' castles (and in my case, tunnels and moats to accompany said castles).

In other words, the game is fun because physics are phun (as is, surprisingly, Engineering), and the game's foundation is a cartoony approximation of physics on a 2d-plane that would make Newton proud and quite possibly queasy. The game understands that a sense of true interaction is a videogame's greatest asset; your in-game cursor leaves an ink-blot trail as you whip it around, frantically grabbing goo-balls who stop and stare at you with a satisfying "pop" as you mouse over them and who scream in zany mixtures of terror and glee when you throw them or, more constructively, incorporate them into a structure you're building. The constant feedback gives the player a sense that they're really an integrated part of this quirky, sarcasm-laced world with direct influence on its viscous inhabitants. Couple this with consistently inventive and imaginative level design that requires an ever-increasing intuitive understanding of the physics (each new level builds on the skills learned in the previous ones without ever repeating quite the same scenario) and a sometimes esoteric but always amusingly satirical sense of humor (with plenty of jabs at corporate America) and you've got a game that blows most big-budget productions out of the water (did I mention it was made by two guys whose office is whatever coffee shop they decide to go to on a given day?).

If the gameplay sounds very vague and confusing, it's because trying to describe in words such an original concept is akin to listing off a series of notes to convince someone that a melody is compelling. You really need to play a bit of the game to get a feel for it, and you can!

You can purchase the game from a host of places (including WiiWare and soon, the iPad) but if you buy direct from the dev's site this week only, they're donating 100% of the sales to some good charities.

Arbitrary Rating: 348 goo-balls

A new era for Pearls on a String

Following in the footsteps of some friends, I have decided to sporadically (which means there may be only one entry) review videogames on this blog that has been serving no purpose for the past few months in a series I will call "Why it's Fun".

These entries will, apart from the rest of this sentence, not be concerned with the ongoing "can videogames be art?" debate, which has wasted everybody's time in the wake of some old guy's rants that, while quite intelligent, aren't at all fair in an apples vs. oranges type of way (a tip: you can't judge an inherently interactive medium by watching YouTube videos about it; you aren't experiencing it as intended!); Rather, I'll treat these games as meticulously constructed experiences and leave what to call those experiences to you, dear lone reader of this blog!

But enough abstract pretentious blithering and onto specific pretentious blithering...

ABOUT VIDEOGAMES!!!

English is a Minor thing

I have become a medium through which words travel,
not a locus of their temporal deconstruction/assemblage-

a reader:

a plane upon which words flow and diverge and bead and flow again
from (and back to) the infinite and infinitely elusive edges

Belated Blog

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

Good News for the DS port

Last week, I restructured the DS loader to use a SeekableReadStream for file reading. Once that was in place and working, I restructured the PS2 loader to use a SeekableReadStream as well and tested it (this needed to be done anyway and it helped me ensure there was nothing inherently wrong with the way I was using SeekableReadStream in the DS loader).

I then had problems reading the symbol table in successfully. After some wasted time :P, I realized it was just a silly mistake. I had neglected to initialize _symtab_sect to anything in dsloader.h and the value of uninitialized ints is undefined in C++. Thus, the loader was detecting, from the value that _symtab_sect had, that the symbol table was already read in when it wasn't.

At this point the loader was getting to the point where I had to deal with the relocations. I used consolePrintfs to make sure that the relocation types the loader was detecting were the same as the ones detected by arm-eabi-objdump (they were). I then began coding for these relocations. After a day of work on the relocations with no success as far as getting games to run with dynamic plugins enabled on the DS, I decided to disable the thumb-interworking on the ds temporarily so I could work on getting the DS with plugins in a runnable state without having to deal with the complication of thumb instructions/relocations.

I worked further on the relocations yesterday; I started dumping the instructions to be relocated and immediately noticed a MAJOR problem. Every instruction was 0x00000000! The addresses of the instructions seemed reasonable, though, so I suspected it had something to do with how the plugins were being built and not how I was retrieving target addresses. I dumped Mapfiles with "-Map" during plugin linking and discovered that whole input sections were being discarded, among other problems. After switching out the linker script for a modified version of the default "arm-eabi-ld" linker script, these problems seemed to be fixed, perhaps because the modified linker script I was using (based on the script used by the main executable) used the MEMORY command to map out different blocks of memory but I was trying to force the start address of the ".text" section to be 0. I am not sure whether switching out this linker script will cause problems.

I then did a fair bit of reading on the ARM instruction set and continued tweaking/testing the relocation code. Things still weren't working like they should have. Yotam suggested comparing completely unrelocated code and semi-relocated code to see what ld was already doing for me, and through a few dumps, I realized I was trying to do A LOT that ld already did redundantly and thus messing up things that were already fixed! After removing this redundant code, I got Beneath a Steel Sky to run successfully with Dynamic Plugins enabled on the DS!

My next order of business, then, is to test the rest of the engines (some of which have relocation types I still haven't dealt with). Then, I'll reintegrate the thumb-interworking and deal with any major complications that brings (if any :D).

~Tony

Also, I plan to update my wiki schedule shortly: http://wiki.scummvm.org/index.php/User:Toneman

a size-able problem with plugins

While working on changing how the loader opens and reads plugin files on the DS this weekend, I noticed that the ".plg" files produced in my builds were significantly smaller than expected (as in under a hundred kilobytes).

So I looked through verbose build output to investigate what the problem could be. The plugin linking output included all the necessary object files, so I knew the problem wasn't there and decided to look closer at the plugin flags.

Last week when I added the PLUGIN_LDFLAGS into the ds/arm9/makefile, I copied over the regular LD_FLAGS to make sure all the special DS optimizations that occur when linking the main executable would be used for the plugin files as well (stuff like "-mthumb-interwork"). One of these flags was "--gc-sections" which I believe is meant to garbage collect sections full of unused functions and/or data. Since both the main executable and the plugin files were using this flag (but plugins aren't truly linked in to the main executable until run-time), functions and data in the main executable and the plugins that point to each other and nowhere else were mistakenly garbage-collected. After removing the "--gc-sections" flag from LDFLAGS and PLUGIN_LDFLAGS, plugins are a much more reasonable size. Unfortunately, this means the main executable is a bit more bloated than before, which runs counter to the goal of using as little memory as possible on the RAM-starved DS...

But for now, I'll be moving on to reworking the loader to use "Common::SeekableReadStream" to read plugin files.

~Tony

plugins linking on DS

I worked through some build errors, switched my plugin.ld to use a modified version of the correct linker script and added a number of PLUGIN_LD_FLAGS (including "-mno-crt0 $(DEVKITPRO)/devkitARM/arm-eabi/lib/ds_arm9_crt0.o"), and plugins started linking. I had some trouble with plugin.ld syntax errors, but figured it out (I was doing things in SECTIONS like "{ contents } >region =fill :phdr" when it needed to be "{ contents } >region :phdr =fill"). Using objdump on the plugins, it seems most only have one relocation type to worry about (R_ARM_ABS32), but the cine and cruise engines also use R_ARM_THM_CALL and R_ARM_TARGET1. I'll be working on completing dsloader.cpp (including the ARM-specific relocations) now, my first milestone being getting one of the engines that uses just R_ARM_ABS32 working.

DS Update

Work on the DS dynamic module loader is progressing. In the tail end of last week, I put the basic loader code in for the DS and modified the default arm-eabi linker script to make a plugin linker for the DS. This week I found (in a .spec file included in one of the makefiles for the DS) that the DS port doesn't use the default arm-eabi linker so I'll have to modify the one it does use (ds_arm9.ld) instead. At the opening of this week, I took some time to try to understand the Makefiles for the DS (it's a bit more complicated than the other ports I've worked with) and then started modifying them to use dynamic modules. I had a bit of trouble getting make to attempt to link the plugins, but after correcting some dependencies, linking of plugins is attempted (though not completed successfully, which hopefully will change once I switch to a modified version of ds_arm9.ld for plugin linking). I'll post again once the plugins are successfully linking.

:-)

Tony

This week has not been the most productive thus far (though it's only just begun). I've been trying to get engine plugins building for the ds (using the custom "plugin.ld" linker script) so I can begin work on the ARM-specific relocations needed for the DS, but the way I've modified the DS makefiles, engine plugins don't build. (I currently get things like "warning: overriding commands for target 'plugins/scumm.plg'"). I'll be contacting Niel to better understand the DS make system shortly.

New Schedule up on Wiki

Check it out :-)

http://wiki.scummvm.org/index.php/User:Toneman

Restructuring

So the way the plugin loader/linker code currently works (on PS2, psp, Dreamcast) is this:

• We build a main ELF with an absolute position in memory.
• We use a custom ld linker script to link together relocatable plugins. Since the main ELF has absolute addresses, some of the more complicated jumps (like those from plugin code back to the main ELF) can be resolved during this pre-linking without the need for us to write explicit loader code for them.
• Our loader code shifts the location of a plugin in memory and adjusts relocations within the plugin.

Doing things this way (with a non-relocatable main executable and a custom ld linker script for plugins) saves us much of the more extensive and complicated work (such as maintaining a Global Offset Table).

Over the past couple of days, I've come to understand (though I'm not 100% sure) that the Wiz is unlike most "smaller targets" in that its launcher requires Position-Independent-Code. This poses quite a big problem seeing as the way we're doing things depends on the main executable having absolute addresses that the ld script can use. To implement the custom ELF loader/linker on the Wiz, then, will likely be quite an extensive task.

Since (in my proposal) I intended the Wiz to be a testbed for a more crucial target (the DS), I've talked with my mentor about moving on to other work towards supporting the DS and ditching the Wiz (at least, for now).

A good first step in this respect would be starting work on changing the plugin system to support only loading one plugin at a time. Some discussion has gone on as to how to achieve this and I've posted my current (under construction :-)) plans for it on my wiki at http://wiki.scummvm.org/index.php/User:Toneman. I'll be discussing things further with my mentor and posting schedule changes there as well (I'm not absolutely sure about whether Wiz work will continue), but for today I'm going to start looking into the DS port (possibly writing a custom linker for it and seeing what ARM relocation types I need to worry about for it).

objdump-ing

So I was trying to figure out which relocation types I really need to worry about when it comes to the GP2x-Wiz today. After making a number of tweaks to the incomplete loader to get it to compile, I compiled and linked (with my modified ARM linker script) the game engines into plugins. I tried using "objdump" on these plugin files to figure out which relocation types were worth my time, but it kept returning all types as "unknown". After a bit of research, I discovered another program "readelf" that successfully dumped relocation types. I noticed, however, that when I do use "objdump -R" which dumps a dynamic relocation table, I get output for both the main "scummvm.wiz" file and the plugin files. This leads me to believe that the binaries may be PIC, but since the version of objdump I'm using doesn't seem to support ARM (as mentioned before, it couldn't detect the relocation types), the reason it's outputting a dynamic relocation table could be because it's misreading the files, not because the files really are PIC. My goal for this weekend, then, is to become more certain about the nature of the generated files, and then to code for the relocations I may need to worry about, which are listed below (the names of some of these relocations also has me worried about PIC code):

• R_ARM_GLOB_DAT
• R_ARM_JUMP_SLOT
• R_ARM_COPY
• R_ARM_PLT32
• R_ARM_PC24 
• R_ARM_BASE_PREL
• R_ARM_GOT_BREL
• R_ARM_PC24
• R_ARM_ABS32

PS2 GP-relative section success!

As of yesterday, the PS2 port would fail to compile with Dynamic Modules turned on unless I put nothing in the GP-relative section by adding a "-G0" flag to the Defines in the Makefile. Last night (after a discussion with Yotam) I made modifications to the linker scripts used when compiling with Dynamic Modules that got rid of these errors. In the linker script for the main engine, I had an extra zero appended to a hex value specifying an offset from the GP register. Fixing this typo (along with rearranging things in plugin.ld so that the .bss section was no longer assigned to the shorts segment, but rather to the plugin segment) seemed to eliminate the problem I was having with "relocation truncated to fit errors".

Quick Update

Got ScummVM booting remotely on the Wiz via a terminal using the stock USB cable and have printf output (haven't tried GDB yet). Continuing work on the loader, I'll post again once it's in a shape where I can start testing. Once it's working, abstracting a more generic ELF-loader should be quite simple :)

Wiz-tle while you work (bad pun)

After a small amount of testing/altering of the PS2 code, I began work on the GP2x-Wiz this week! On the debug front, I've gotten some help from the GP2x forums to get the Wiz to "pretend" to be a USB serial converter and I've successfully logged onto my Wiz via kermit. Booting ScummVM from remote via kermit isn't quite working well yet, but it's close. On the coding front, I've written a plugin linker script (I don't think I'll have to use a custom linker for the main engine like I did with the PS2 code). I've also decided to prototype the custom ELF loader for the Wiz using a Makefile instead of configure since I might be making significant changes to building. I have a Makefile now that successfully builds ScummVM for the Wiz with static plugins, and am working on the loader.

PS2 plugins working

Work went much better after getting debugging facilities running on the PS2. I discovered the problem seemed to be in how the plugins were linked. After making changes to plugin.ld over the weekend, dynamic modules seem to work correctly, at least for the SCUMM and SKY engines, on the PS2. I'll be doing a bit more testing, but things look good!

Tomorrow I plan to better comment out the altered linker scripts with documentation of what the changes are intended to do. Also, after discussing things with Yotam (my main mentor), I've decided to alter my schedule and begin work this week on the GP2x Wiz ELF loader/linker (instead of the work of abstracting a generic ELF loader). After work on the GP2x Wiz is done, I'll be more able to know what things can be abstracted and what things can't.

The altered schedule (which was approved by my mentor) is up on my wiki page: http://wiki.scummvm.org/index.php/User:Toneman

Debug!

I've been hitting problem after problem getting good debugging support going on the PS2. Lesson learned, I've sent off e-mails to the porters for GP2X-Wiz and DS so I'll be more prepared when it comes to how to print debug output, etc. on those systems :-)

The Work So Far

A summary of my work so far on ScummVM:

• After a bit more hassle than expected (which involved things like changing some toolchain installation scripts to use older svn revisions), I got the necessary toolchains/libraries to successfully cross-compile ScummVM for the PS2, DS, and GP2x-Wiz.
• I copied the psp-provider, elf32.h, and psploader code into the ps2 backend and began tweaking them for the PS2.
• The simplest of these "tweaks" was just changing references to "PSP" to "PS2" :-)
• Tweaks so far also included removing psp-specific things from the ps2 loader (like code that I believe was there to ensure the psp didn't suspend during a load) and in some cases replacing calls to code in the psp toolchain with calls to code in the ps2 toolchain (also being sure to replace "includes" that reference psp toolchain files with "includes" that reference ps2 toolchain files).
• I got the default ps2 cross-compiler ld linker script using ee-ld --verbose and tweaked it in a similar fashion to the way the default psp linker was tweaked for the psp plugins (Yotam provided the default psp linker) to generate plugin.ld (for linking together game engine plugins) and main_prog.ld (for linking together the main engine).
• I tested main_prog.ld with static plugins and found that ScummVM didn't launch on the PS2 using the modified default ps2 linker. I saw in the PS2 Makefile that the default linker was switched out using -T with a "linkfile" in the PS2 toolchain. I remade main_prog.ld and plugin.ld by modifying this instead and it successfully launched again.
• I modified the main (in systemps2.cpp) to check if Dynamic Modules are enabled and, if so, to call PluginManager::instance().addPluginProvider(new PS2PluginProvider()).
• I have spent much of my time making tweaks to Makefile.ps2 (i.e. learning how different compiler flags/Defines affect the building, adding plugin variables, directing that the linker use my linker scripts, ensuring that the ps2loader is compiled and linked, etc.)
• I was getting linker errors concerning the GP-relative data section being over-filled when I enabled Dynamic Modules. I don't see a good reason why this is the case but for now I have used -G0 flags in the Makefile to direct the cross-compiler not to put anything in the GP-relative section.

At this point, compiling with Dynamic Modules turned off works as well as always, so at least my modifications haven't broken anything! :-). With Dynamic Modules turned on, yesterday morning ScummVM booted and let you specify a "Plugins Path" in the options, but failed to find engines for any of the games even though the plugins for those engines were linked. After making some modifications to the makefile and fixing some typos in the loader yesterday, ScummVM won't even boot anymore with Dynamic Modules turned on (might be a simple typo or something more sinister). In light of this, I'm planning to modify my schedule a bit after discussing it with my mentor, but progress is being made!

Note: I've made a number of modifications since my last commit but am holding off on committing code until ScummVM is at least launching again on the PS2.

Some Success!

Got ScummVM on the PS2 building with dynamic modules enabled (plugins linking, too!) Now to start actually testing on the PS2.

A modicum of progress

Finally got the main engine linking without errors when dynamic modules are turned on for the PS2! Now to get everything else working... I think I'll be working this weekend :-)

link or swim

I've been having trouble getting the modified "plugin.ld" script to work when compiling the PS2 port with dynamic modules enabled. I'm going to spend a couple of hours now reading a hundred pages of GNU linker documentation. Having a more thorough understanding of the linker should help since I don't completely get what the default linker is doing :)

Reflections on Week One

Some hard truths I learned during this, my first week of working on an open-source project:

• Everything will take more time than you predict it will :-)
• This Summer will be a learning experience. I think things will go a lot smoother now that I've been humbled a bit and am more comfortable with taking some time to read documentation/ask for advice from other devs when I hit a bottleneck.
• Panera Bread has free wifi and tasty food :-)

Some things I did during this, my first week of working on an open-source project:

• Got MUCH more comfortable with linux (specifically Ubuntu).
• Got the PS2 port of ScummVM to compile and updated the wiki page concerning the process.
• Learned a bit about how GNU linker scripts work.
• Got comfortable merging trunk changes into my branch and communicating with the ScummVM porters (nice people!)
• Modified the PSP loader to work for PS2 and made special PS2 linker scripts (as of now, these are untested).

Day 2

Spent today trying to get ScummVM builds compiled on my machine for all the platforms I'll be working with this summer.

Having a fair bit of trouble with the ps2 build :-)

Turns out tweaks made to the ps2toolchain over the past year make it incompatible with ScummVM's ps2 code, but even when checking out a previous revision of the toolchain, the script that builds the toolchain updates everything to the current revision :P

So I manually tweaked the scripts to check out an earlier revision, which would have worked out fine if ps2dev.org wasn't down ALL day. Luckily my mentor had a link to another site hosting the same code and I was able to make some more tweaks to get the correct revision.

Now I just need some libraries (tremor specifically) and it should be built before bedtime.

Made some progress on getting the others built as well :)

Stumbling Out of the Gate

Attempted to start my GSoC project yesterday, but had a far less productive day than I had hoped. I spent pretty much all of the day just trying to get the PS2 port of ScummVM to build (with no real changes to the code) but the ps2toolchain I set up didn't work correctly. Then I got esoteric svn errors when trying to revert to an earlier version of the toolchain to fix these problems. Frustrated that the ball isn't rolling quite yet, but excited to get there soon :D

Tony

Grrr...

Drove around Sacramento the last couple of days looking for a gameshark or action replay for the PS2 (things that give you means of exploiting and running indie homebrew software on the PS2). No luck... I ordered swap magic discs (another means of exploit) and it seems they only just shipped today (even though I ordered them over a month ago). So looks like I'm headed to Stockton to pick up an exploited PS2 memory card today. Hope all goes well!


UPDATE:

The trip to Stockton was a success! Got a memory card with Free McBoot and successfully ran "Freddi Fish" on my PS2 via ScummVM!

The Wiz

I refer not to Michael Jackson's retelling of Dorothy's journey on the yellow-brick road, but to the fact that I have obtained a nifty little Korean handheld known as the GP2x Wiz and am currently enjoying Full Throttle on it :-)

Brewed at Home

Got ScummVM up and running on the DS. Sam and Max never looked so good :-)

Now to tackle getting homebrew to run on the PS2...

It is the year 20XX

Working on a retro soundtrack for the point-n-click adventure game I'm making;

Here's a preview:

Being for the Benefit of RAM that's tight

For the benefit of anyone interested in what I'll be working on this summer for ScummVM as part of Google Summer of Code, here's a (slightly) modified copy of my GSoC application:

Title:	Implementing Support for Loadable Modules on MIPS and ARM-based platforms
Student:	Anthony Puccinelli
Abstract:	ScummVM has grown to include support for adventure games running on many different engines. This much-appreciated support has unfortunately bloated the size of the ScummVM binary and the space it takes up in RAM, which is a problem for small devices that don't have much RAM to work with. To alleviate this issue, custom module loaders can be written for these devices that enable them to only load one needed engine into RAM at a time, depending on the game selected.
Content:	Name: Tony Puccinelli Email: tony.puccinelli@gmail.com Mentor: Yotam Barnoy Co-mentor: John Willis Deliverables: 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. Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. Implement support for loadable modules on the GP2x, an ARM target. Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code. Benefits to the ScummVM Community: Helps to reduce memory usage for the ports involved, which could especially help the RAM-deprived DS port to be more functional with games like "The Dig" and "Full Throttle". Will help eliminate the need for confusing and difficult alternate versions of the ScummVM binary that hold some subset of the game engines ScummVM supports. Generic “ELF loader” will lay the groundwork for loadable module support in other ports in the near-future. Project Schedule: I’m utterly swamped by coursework this semester, so I can’t commit to coding work until the official start of gsoc according to their timeline (May 24th). I aim to be finished with the project on August 13th to leave a little time for some refining/testing/debugging work the last weekend of the program. I’m interested in continuing to contribute to the ScummVM project after gsoc is over as well, perhaps by attempting to more fully support the DS. A more detailed schedule follows (I am currently planning to work 7-8 hours a day M-F. This schedule is DEFINITELY subject to change as I imagine I will have to be quite flexible if unforeseen problems arise): Week 0 (May 17 - May 21): Poke around ScummVM code :-) Ensure I am up and running with homebrew on the DS, PS2, and GP2x. Week 1 (May 24 - May 28): Tweak PSP loader code for PS2. Write custom GNU linker script and modify PS2 port's Makefile to get plugins to build properly. Week 2 (May 31 - June 4): Finish/Debug Week 1 task. Week 3 (June 7 - June 11): Generalize an "ELF Loader" that all ports can inherit (this may be similar to "elf32.h"). Week 4 (June 14 - June 18): Finish/Debug Week 3 task. Week 5 (June 21 - June 25): Better familiarize myself with ARM. Write a GP2x loader. Utilize GP2x's Linux capabilities to aid in debugging. Week 6 (June 28 - July 2): Continue work on GP2x loader. Start writing linker script and modify Makefile to get plugins to build properly on GP2x. Week 7 (July 5 - July 9): Finish Week 5 and 6 tasks. Week 8 (July 12 - July 16): Begin work on DS loader/linker. Modify loader to load only the engine of the desired game instead of loading all of them, then deleting. Week 9 (July 19 - July 23): Continue work on the DS. Week 10 (July 26 - July 30): Continue work on the DS. Week 11 (August 2 - August 6): Finish work on DS. If time allows, begin turning audio codecs into loadable modules (work that might continue after gsoc). Week 12 (August 9 - August 13): Final Testing/Debugging/Refinement phase. Availability: I plan to treat this as a full-time job, and will thus make myself available to work 35-40 hours a week. I have made no other major commitments this Summer and am willing to up the time I work each week if necessary. I am also willing to add more to the project if it turns out work goes quicker than expected (though from my prior programming experience, I've found it is far easier to underestimate how much time a task will take than to overestimate it). Skype ID: toneman73 Phone Number: (916) 616-5265 Timezone: Pacific Standard Time (I'm in California) Bio: I am a Junior CS major and English minor at UC Berkeley and a long-time user of ScummVM. I am passionate about interactive storytelling and love adventure games for their focus on smart dialogue and tongue-in-cheek humor (In fact, a friend and I are VERY slowly beginning work on a point ‘n’ click adventure of our own using Adventure Game Studio). On the technical side of things, I am well-versed in MIPS as I’ve not only written MIPS code, but have written an assembler that translates a simplified, 16-bit version of MIPS dubbed CAL16 into machine language. I’ve also designed a circuit (using LogiSIM) that can take a CAL16 program into RAM and run it. Thus, the PS2 task is right up my alley. My current coursework involves writing a Python compiler in C++ and implementing features like caching and virtual memory mechanisms, CPU scheduling, multi-threaded processes, etc. into a simple OS dubbed Nachos. These projects are, I feel, uniquely preparing me for the type of work I'd be doing with this task, work that specifically concerns the hardware/software boundary. Thanks very much for your consideration; I'm looking forward to the possibility of working on this project, as it is one I've respected and used for years.

Le Code

Got into Google's "Summer of Code" program. I'll be working for the open source project "ScummVM" over the summer! Very excited :-)

Wait... this blog isn't supposed to have straightforward and sincere descriptions of what's going on in my life; it's supposed to be a stream of self-deprecating, tongue-in-cheek comments (an arrogant showcase of how witty I think I am)! What's going on here!

Engagement Advice

I am engaged. This fact is awesome.

But to all of you nincompoops out there who have not yet discovered the ironic sense of freedom that can come from binding oneself to another for life, here's some engagement advice:

• You're a man (unless you're not). Totally not outdated social norms (totally) dictate that YOU MUST BE THE ONE TO PROPOSE!
• Since you (as the man) are the one proposing, you are the one who's going to pick out the ring. Don't let that silly "love of your life" girl have a say in what kind of bling she's gonna be stuck with for the rest of her life!
• If she does try to hint at what kind of ring she desires, simply say, "Remember Christina Hartnell?" (Note: any made-up name will do) When she replies in bewilderment, "The name doesn't ring a bell..." respond with a triumphant, "and a belle doesn't name the ring!" She'll be so stunned by your witty wordplay, she'll lose her grip on that misguided sense of boldness she was holding onto.
• Oh, and remember to be respectful to women and stuff or whatever.

Tony

Caution: Blogospheric Pressure Increasing

Why this blog is called "Pearls on a String" (a list):

• Pearls are precious; So are you, imaginary readers!
• One of the side-projects I'm eager to work on is a point-n-click adventure game. A common design philosophy for such games is to have the player work through sequential episodes that are somewhat self-contained; kind of like pearls on a string.
• You have heard it said, "People never change." I tell you the truth, that's a load of fine, north-Italian bologna! People's interests/personalities/opinions change over time, making each phase of life refreshingly unique! Thus, in an awkward and forced way, I think of "Pearls on a String" as a metaphor for the journey of life itself, and this online journal may end up being a document of my journey.
• If pearls don't have a string, they're basically just really sucky marbles.
• If the string doesn't have pearls, you've bought a really sucky anniversary gift.

What a fine title!

[A Profound Title/A Sly and Sardonic Title]

This first post is a choose your own blog-venture! [Decide/Pretend you know] what I mean to say!

Why hello [your name/amigo/amiga/George Washington]!

I'm so glad you found time in your [busy/chaotic/packed/so open it's boring] schedule to visit my [lowly/infantile/intellectually fascinating] new blog-o-thing!

I've been thinking a lot lately about how people don't [pay attention to/heap praises upon/hand fistfuls of cash over to] me enough, which is a bit strange given how [awesome/pathetically insecure] I am. I figure there's no better way to [encourage/dissuade] such [behavior/behaviour] than to start my very own [blog/blog] in [lament/celebration] of my impending [birthday/doom]!

[Enjoy/Loathe]!

[Anth/T]ony