Windows-Compatible .gpl Models

After having success exporting 3DS Max projects to gpl format, I decided to dive further.

The Dolphin Emulator e28 from the Gamecube SDK comes with a modified version of the 3DS Max plugin CPExport. This new version, called MaxConv.dle, is capable of exporting little-endian files.

I exported the Zebra demo from 3DS Max using the new plugin.

I opened up previewerD.exe and it was actually able to load the newly exported gpl.

Tiny .gpl zebra, now on Windows!

I was even able to navigate the previewer (somewhat) using my Logitech F310 controller. With that said, only some of the buttons would work:

  • Primary stick (mapped to my left analog stick)
  • Trackball/light control switch (mapped to Y on my controller)
  • Zoom out (mapped to A on my controller).

Most notably, the zoom in function is not working with any of the buttons on my F310.

I’ll try my controller with the iBook to see if it works. I also have a USB PlayStation 3 controller that I’ll try out on both the Windows and Mac versions of Previewer.

Even though it seems helpful to have models opening on the Windows version, it will only accept custom-exported gpl files. I might try looking at the gpl files in a hex editor to find exactly how the data is organized compared between Windows (little-endian) and PowerPC (big-endian) versions of the plugin.


Update: If I unplug my controller, the emulator defaults to keyboard controls:

Key Controller
Arrow keys Main Stick
`A’, `S’, `D’, `W’ Sub Stick
NumPad 2 A button
NumPad 4 B button
NumPad 6 X button
NumPad 8 Y button
NumPad 7 Trigger Left
NumPad 9 Trigger Right
NumPad 0 Menu button

This means that we can finally zoom in on our model using the Windows previewer (provided that the gpl file has been exported as big-endian).

Not-so-tiny zebra

An update on the Windows version of “Previewer”

After setting up a full software development environment in a Windows XP Virtual Machine using a combination of Visual Studio 6.0 and software from a recent AssemblerGames dump, I was able to make some progress with the SDK files.

I managed to delete the version-check code from C:\pcemu\build\charPipeline\geoPalette\src\geoPalette.c (a module used when previewing gpl geometry files).

I was then able to recompile geopalette.obj and charpipeline.lib (using the newly modified geopalette.c code) by opening C:\pcemu\build\charPipeline\win32\makeall.bat.

Once those were created, I could finally rebuild Previewer.exe and PreviewerD.exe (debug) by running the makefile located at C:\pcemu\build\demos\charPipeline\pcmakefile.

This means that the program will bypass the previous version mismatch error I was getting.

However, the program still will not actually load the model, and will crash shortly after displaying the “Loading” message.

After looking at the documentation that came with the SDK files, it seems that this issue is because the Windows version of Previewer needs gpl files exported specifically using little-endian, as opposed to big-endian (typical format for exporting for Gamecube/Mac test systems).

My best bet at this point would to continue my search for an OS 9 mac that I can run further tests on, or to find a way to convert the big-endian gpl files to little-endian for viewing on PC.

Endian Differences between the Gamecube and PS2

Upon review, it seems that the Gamecube primarily stores data using big-endian (a type of data encoding), whereas the PS2 primarily stores data as little-endian.

This means that some game data (e.g. dialogue files) might appear to have their data “flipped” when comparing the GCN and PS2 versions.

As an example, a section of data might be “cdc3b0b0” for a file in the PS2 version, but “b0b0c3cd” in the GCN version.

This means that certain files were re-encoded when the game was ported to the PS2 to avoid them from being read as corrupt.

Shoutout to Dahni in the Discord chat for making this discovery.

It’s unclear at this time exactly which files were re-encoded. It seems that dialogue files were altered at the very least, but this could extend to other file types (textures, models, etc).

With that said, I’ll be focusing exclusively on the GCN versions of the game files to prevent any confusion of endian encoding going forward.