We have Zebra!

A while back I tried running a program called previewer for viewing .gpl files (3d models).

There was a version of this program compiled for classic Macintosh computers. Since these computers (notably the PowerMac G3) had similar internal architecture to the Gamecube, they were used as testing environments for some areas of Gamecube development.

I had set up an emulator called SheepShaver so that I could try running the program. Unfortunately, SheepShaver (and all other modern classic Macintosh emulators) lack support for hardware-accelerated graphics. The lack of hardware-acceleration means that the previewer would not render correctly and would just lead to an empty black box.

I emailed around to a few used computer shops and managed to snag an old iBook G3 for $50.

The leaf fell off and the battery’s dead, but it still works just fine (when plugged in).

After setting it up with a copy of Mac OS 9.2.2, I was able to try launching the previewer program once again.

Unfortunately it got hung up a few times when trying to render some gpl files from the SDK.

Fortunately. I was able to open one of the 3DS Max projects included with the SDK. Special thanks to Video James (sonic15783)#6150 on the Discord for helping me get a copy of 3DS Max 3 up and running in my virtual machine!

Zebra.max in 3DS Max R3 3.0 in my Windows XP virtual machine

I was then able to export this from 3DS Max to a .gpl file using the cpexport.dle plugin included with the SDK Character Pipeline.

I tried previewing the gpl on the SheepShaver emulator (just to check if it was the emulator causing issues). Sure enough, I got the notorious black rendered screen.

Black screen render in SheepShaver

I tried viewing it on my iBook and, to my surprise, it rendered!

We have tiny .gpl Zebra!

Unfortunately the program freezes after this point and I have to force it to quit. This could be due to a number of reasons:
– The program might require a controller to function at all when something is rendered
– The laptop might not be powerful enough to do anything else once the model initially renders (doubtful)
– The program might be designed to function minimally in a mac test environment
– Something else

If anyone has a classic mac and would like to try out the Zebra demo, I’ve created a disc image [download]. Just burn the image to a CD and put it in the mac, then copy previewerD.bin to your Desktop and double-click to extract the program. Then, just double-click the newly extracted program to load the demo.

At this point, it’s a lot better than nothing.

I’ll try out some Harvest Moon gpl files over the weekend and see if I can get anywhere, of if I just get more black screens.

Getting Closer to 3D Model Previews

Namely, there was a “previewer” program compiled for old macs (old macs used a PowerPC architecture, similar to the Gamecube and Wii)

I’ve been fiddling around with some of the files from the Dolphin SDK.

I had tried running this before, but got stuck on the program looking for a “prevload.txt” file in a specific directory.

After some digging around in various documentation and script files, I finally figured out what I needed to do.

The program looks for an inserted disc with the volume label “cp”. It then looks for the folder “cp:/cpdata/preview/”. This folder must contain the file to be previewed (in this case, Zebra.gpl) as well as a text file called “prevload.txt” (which just contains the name of the file to be previewed).

With all of these conditions met, the program should display the requested file.

Unfortunately my virtual machine setup seems to freeze (or in some cases crash) at this point. This seems to be an issue with SheepShaver not supporting 3D hardware rendering.

Ultimately, the next (and only) step to get this software running would be to try it out on a real old-school mac. And even if that works, I’m not sure whether I’ll be able to navigate the program (since it seems to use some sort of game controller).

As always, I’ll keep you all updated.

Decompiling the Game

Good news!

Avast has released the source code for their Retargetable Decompiler (RetDec for short).

Why am I excited about this?

Because can decompile PowerPC binaries (i.e. elf files) into a programming language (C or Python).

The main executable program in any Gamecube/Wii game is a Start.dol file, which is a variant of the elf format.  Also, the GC/Wii are both based on the PowerPC architecture.

Most decompilers will only break a game down into what’s called Assembly.  This is a type of machine code that is difficult at best to reverse-engineer.  And those that support recompiling to other programming languages typically only support the x86 architecture.

Previously, one could try RetDec online, but it had a very small limit on decompilation time (which was not enough for a file as large as the game’s main program code).  But now, I can run it on my own machine for as long as needed to run the decompilation process.

I’ve been able to successfully install RetDec and it’s dependencies.  I was then able to convert AWL’s Start.dol file into a Start.elf file using DolTool 0.3 and begin the decompilation process.

Unfortunately the decompilation failed part-way through due to not having enough memory (my laptop only has 4GB RAM).  My roommate offered to let me try on his laptop (which has 8GB), so once I’m able to try on that, I’ll post an update.

From the partial decompilation, I can tell that I’m on the right track though.  I’ve been able to find a few lines in the LLVM code that reference CLZ files and could be the key to their decompression algorithm.

@global_var_80298180.828 = constant [22 x i8] c”mainchapter%d.arc.clz\00″

%v4_800131f8 = call i32 @function_80238268(i32 %v2_800131f0, i32 ptrtoint ([22 x i8]* @global_var_80298180.828 to i32), i32 %v0_800131e8)

It appears that the clz file is passed through to a variable, which is them passed through some sort of function (possibly to be decompressed).

I’ll be analyzing this code as much as I can to try and figure out how the files work.

On a separate note, decompiling the game’s primary source code could create a better understanding of the game overall and could open the door for additional future mods from other authors..


I tried running the decompilation on my roommate’s 8GM RAM machine, but it still failed after running out of memory (though at a later point).

But on the bright side, I was eventually able to get the decompilation to work by turning off code optimizations with the –backend-no-opts flag in retdec.

The main downside to this is that the code is much larger and complicated than it would be if I had been able to run the optimizations.

function_80238268(v105, (int32_t)“mainchapter%d.arc.clz”, v35);

At least it’s somewhat easier to follow now than the partially-decompiled LLVM code obtained previously.

If anyone has a machine with higher memory (e.g. 32GB) you could try running RetDec to decompile the binary yourself.  I’ve made a downloadable [folder] with all of the needed files, including an installation guide to get everything set up.

[Please PM me if you’d be able to help out with this]

For anyone else that feels like helping out, I’ve uploaded the decompiled source code [link].

The code is unfortunately fairly large and unoptimized.

I have versions written in both C and Python.

Please feel free to take a look and see if you can find any useful information.

SDK Software

I managed to figure out some of the software from the Gamecube SDK.

It looks like some of the SDK includes binaries built for the legacy mac platform.

Old Macintosh computers used the same PowerPC architecture (as opposed to other computers that used the Intel x86 architecture) as the Gamecube. This means that running software for the Gamecube would require either the actual dev kit hardware (known as HW1 or HW2), or a Mac.

There was also the official Dolphin emulator (not to be confused with the current fan project Dolphin Gamecube/Wii emulator), but that could only emulate certain aspects of the hardware.  You’d still need a mac or dev kit to run most things.

So, after some trial and error, I managed to get an old copy of Mac OS 9 running in a virtual machine known as SheepShaver.

I then got the preview program (an app from the SDK to view the character models/textures) to extract and open.  But when trying to run it, it fails after saying a needed file (prevload.txt) couldn’t be found. Documentation on getting this to run is sketchy at best.

I’ll need to do more digging to figure out the full configuration needed to get the app to run.  I read something about setting “CP_Root environment variables” in the SDK documentation, so that might be my next step.

I also tried getting my hands on a trial copy of 3DS Max (the software used by devs to create models). But then I found out that 3DS Max Plugins are version specific, so I’d need the old 3DS Max v3.1 to use the Gamecube plugins from the SDK to import/export models. And this will likely also require I use a virtual machine with an old version of Windows (e.g. Windows 98) to run it.

One step forward, two steps back.