Tips on making a GameCube Dev Unit

[StarkNebula]

I'm going into Game Design this september and thought it would be cool to make a GameCube game some day. I'm currently working on decoding some of F-Zero GX's files so that I can make tools to create TPLs. Consequently, I'd be able to make games using those tools (though this is pretty far out, I'm still learning Python, let alone C and any C derivative.) There's a bunch of logistics I have yet to solve, but it's something I want to do within the next 5 years.

To start things off, I'd like to make a dev unit mod on a GC. I'm thinking HDD (though I'm not sure if HDD is better or worse than SDXC, or what not.) I'd need info on that. Basically just a plug'n'play disk to choose ROMs from. Also, if anyone knows where to get a USBGecko in this day and age, that'd also be awesome. Anything that comes to your minds, let me know.

Any info on game engines, how to build debug tools, file formats, etc would be appreciated. Yes, I already know of YAGCD. ;P The more information I hoard, the more likely I am to read through it every-so-often. I'm not sure if there's a GC game tutorial out there, though I do have a bunch of GC tools (GCE1.06, GCR1.0, etc) which cover a bunch of the reversing-engineering/building process. Again, the software side of it all is arbitrary at this point, but will become relevant soon enough.

So, anyone got good ideas of what a GC modded into a dev unit should have?

[novenary]

Any modchip with an USB Gecko will do actually. Wii Key Fusion's SD slot is still better than IDE EXI as of now though so you might want that. Especially if you don't plan to use audio streaming. You need an SD Gecko too to write data to (memory cards are small).

[theclaw]

For authenticity, the USA/JPN switch if NTSC. Units like NR Readers have one.
Besides as you should already know Japanese version F-Zero GX needs that to play correctly.

[Dragoon]

Well first things first, are you going into gameDESIGN or gamePROGRAMMING?
Since you're speaking about programming languages, I assume you're going to do gameprogramming.

First of all, you need a gamecube, that's pretty obvious isn't it?
Some nice tools to have for development are a USBGecko, BBA, Qoob/Viper.
Why not a Xeno? Well, as far as I'm aware, there are no tools for Xeno that allow you to boot a DOL directly, while the ViperGC (extreme) and Qoob do.
A ViperGC Extreme with the latest Cobra BIOS allows you to boot DOLs from USB. I'm not sure if GCoS fits on a regular Viper, but if it does, it will allow you to boot DOLs directly over BBA.
The Qoob allows you to boot DOLs over BBA too.

I advice you to get at least a BBA, this allows for faster streaming than the Gecko (to my knowledge). You need either one of those 2 to debug your DOL with a remote debugger.
An SD Gecko is nice too if you plan to support saving to SD.

Now to the software.
There aren't any open source game engines available that are written with devkitpro.
But we can write our own.
Devkitpro comes with a set of tools like a compiler, remote debugger, texture converter (gxtexconv). The texture converter allows you to make those TPL files from various texture formats and puts them in the TPL at various compression levels.

I advice you to build the following features in your game (engine):
- Asset streaming over USB/BBA.
- The asset server (for streaming the files to the gamecube).
- Write a program that puts your game in the standard GCM format. (You need to write code that loads the files from the DVD though.)
- Cross compiling on your computer.

As for debugging, look in the gdbstub tutorials and figuring your way out with insight is pretty easy too. Either connect over COM or TCP and load the ELF and you're ready to go.
As for the programming language, my language of choice is C++ (constexpr and templates for king! ), but C is fine too.

I wish you good luck on your adventures

P.s. This is a nice tool for profiling your code: http://libprofile.googlecode.com/files/ ... lev0.1.zip

[StarkNebula]

Streetwalker: Thanks, though I do plan to use audio at some. I'll probably go with Qoob as Dragoon mentioned.

theclaw: Yeah, I already have a JP modded GameCube for that reason! Fair to say I recognize you from TCRF, with some of the edits you did on the F-Zero GX page.

Dragoon: Actually, the proper course title is "Bachelor of Game Design," so it is indeed Game Design. The courses are include programming, but from what I can see, nothing too hardcore. To compensate, I'll try and learn something deeper on my own time.

Thanks for the advice. I'll start by making the dev unit, slowly but surely. Once I get around to C/C++, I'll start fiddling around with demos.

[novenary]

I was talking about the ADPCM feature that lets you stream tracks from a DVD and that only works from the DVD drive. You still get regular DSP audio without that.

[tueidj]

It's a lot simpler (and possibly cheaper) to do development work on a wii:
- built-in wifi
- HBC for easy over-the-air loading direct from a PC
- built-in SD port for storage
- USB ports for HDD, usb2serial debug, anything else you want to plug in (other controllers etc.)

They're basically the same system "under the hood"... only major difference is the wii has fancy controllers.

[emu_kidid]

Yes, from what tueidj has said, the boot cycle to load fresh code is typically a lot faster on a Wii, to get about the same on a GameCube it'll cost you a bit as it requires certain homebrew hardware that may be hard to come across now:

GameCube (any region) DOL-001 (so you can develop it to support progressive mode too)
Qoob PRO / Viper GC
USBGecko (to load code over)
SDGecko (to store data on)

If you are developing a game, I'd recommend developing it on SD first (you can read up to any size SDXC card via SD Gecko), and then adding in any DVD specific things (you talk about Audio streaming, but really, what's the point when you can't really rely on modchips/drive patches/disc loaders getting the audio streaming bit right).

With the USBGecko and a IPL replacement modchip (the Qoob/ViperGC are good enough), write a tiny UIless loader that just waits for a DOL over the USBGecko and executes it once received, this is what I've done. I have it as a Viper plugin or as a Qoob PRO flashed file so boot up time to load code is instant.

[StarkNebula]

I didn't even realize I could utilize the Wii's Wi-Fi for remote loading, as well as using the USB ports for debugging. Couple that with the fact that I can easily use a cheap component cable to support 480p. Seems a lot more like the way to go. Thanks guys. Looks like I'll need to go find some Wiis. :P

Thinking of it now, is there anyway to utilize the Wii's MEM2 for anything else? (Debugging, etc.) Not sure if I can touch that while using the MIOS.

[tueidj]

You can't use MEM2 while running in gamecube mode. You can't use USB or wifi either.
If you really want to limit your game to gamecube (not wii) then develop/debug it as a wii program without using any of the wii specific features, then once it's finished/working just switch the makefile to target gamecube instead.