Where to begin?

[Sage of Mirrors]

Hypothetically, if wanted to make something that could, say, view models/areas from a Gamecube ISO, what would I need to do on the ISO side? What exactly would I have to figure out?

[xdaniel]

First of all, see if there's already a program that might be capable of loading the models you want to view. Consoles/handhelds with filesystems tend to use standardised file formats for models, textures, videos, sounds, etc., recognizable by the file extension or the first few bytes in the file (often an ID of a few letters) Not all developers use such, however, so chances are that there isn't a tool for that specific file type yet.

 

If there's no tool, check if there's at least existing documentation about the format (maybe incomplete, otherwise there would probably be a tool) which should help when starting out writing a model viewer; technical docs about the system itself are useful, too. Then - unless you know your way around emulator's debugging functions, if they even provide some that might help here - poking around the files with a hex editor tends to be the next step. Identifying what files contain what and where is easier nowadays, because of file extensions, in-file IDs and plain filenames, as compared to ex. N64 ROMs which are, at the first glance, just big binary blobs.

 

Hypothetically speaking, you've got a 3D adventure game or RPG, and there might be a file called "twn001.lvl". The filename already implies that it might be related to a town ("twn"), and that it might be the actual level data ("lvl"). Using a hex editor, inside you might encounter short ID tags like "LEVL", "TXTR", "VRTX", "POLY" or so, which denote what kind of data follows - after "LEVL" might be things like the level's in-game name, "TXTR" might be followed by the level's textures, "VRTX" could be followed by the vertices that make up the model's polygons, "POLY" might be the actual polygon definitions. It's more or less about recognizing possible structures inside a binary file - "similar looking" bytes of data, repeating in a specific pattern of maybe 16 bytes of length, might - for example - be a list of vertices; a vertex on the N64 looks kinda like this, 6 bytes of X/Y/Z position, 4 bytes of S/T texture coordinates, two null bytes, 4 bytes of R/G/B/A coloring (or vertex normals, but that's another subject). Byte alignments are another thing to look out for; to take the N64 as an example again, depending on what kind of data it is, it has to start on an even number - display list commands, for example, are 8 bytes long each, and have to start at either x0 or x8, so ex. offset 01A28 is okay, while 01A2A or 01A23 aren't.

 

I hope that helps somehow, and doesn't sound too difficult or anything. It is difficult if you've got nothing to base your work on, like documentation etc., but even then it's not impossible - the first emulators to come out didn't have the luxury of leaked official documents to tell them how things worked, either

[Sage of Mirrors]

I see...

 

Well, I did the first thing you said, searched for anything already made... for the specific game I was looking for, there wasn't anything made...

 

I'll have to look into it. Maybe I should start with NES games first, though? I am pretty new at this, and I have a habit of etting ahead of myself (its too complicated, and I only spend a day or two trying to figure stuff out before I get tired of it.)

[Secant]

NES games are a great place to start. When you're trying to learn how to document file formats, this is one scenario where reinventing the wheel is actually a good idea. This way, you can follow specific steps and achieve a known satisfactory result to get the hang of what needs to be done to achieve a certain purpose. Once you've grasped the concept of an NES game's file formats, you might step up to a slightly more complex 2D console, such as GBC or GBA. From there, you could try moving on more complex yet, with the N64, until you feel comfortable enough to tackle complex GCN file formats. Spend as much or as little time as you feel comfortable doing with each one; take your time and try to challenge yourself to keep your own interest, but avoid anything so daunting that you're certain to give up before you accomplish your goal.