Mario's gonna kill me when he finds out what I did to his fence. 
I'm sure you can guess what this is. I'm tired, so I'm just gonna post my notes here. Table stretching and double-spacing is because HTML fails at preserving spacing.
Debug mode (the Gameshark code):
Key combos in debug mode:
R+B: Toggle CPU usage display
Up: Put you and everyone behind you on lap 3 (position won't update while standing still)
Right: Put you and one other person on lap 3
Down: Put everyone on lap 3
L+R+A+B: Reset; if Z is held, coordinate display is enabled (will be on until turned off); if not it's disabled.
Z or C-Down: Press during race start sequence to start early
Interesting note about pressing Z or C-Down to start the race early: Both of these buttons are used for items. However, the effect is not caused by a special 'debug item': Using an item modifier, you can have an item and still do this. (Also, it starts the entire race early; you don't get a head-start. It's meant so you don't have to wait for the whole start sequence. However, doing it before everyone is in place causes problems.)
TKMK graphic files:
TKMK seems to be the header of another type of file, like MIO0. I have yet to examine the file format but it appears to be used for graphics. There are 63 of these files in the ROM. The first 16 bytes are as follows (taken from the first file):
#0 1 2 3 4 5 6 7 8 9 A B C D E F
54 4B 4D 3B|30 30 06 0F|00 DC 00 20|00 00 06 B8
T K M K| 0 0 | |
0-3: Always 'TKMK'. Changing this doesn't seem to do anything. Likely just indicates the file format.
4-5: Always '00'. Not sure what this does. Could be that the header is actually 'TKMK00', but having a 6-character header seems odd.
6: Usually 06, sometimes 82. Changing this messes up the graphics.
7: Always 0F.
E-F: Seems to be a palette pointer. Unusure how many bytes, likely 2 or 4. It is, in fact, possible to crash the game by changing this (changing it to 0098 in the file at 7FB8C0 causes this). If it is indeed a pointer, it would seem it has to be 16- or 32-bit aligned. This was tested using the file at 7FB8C0, assuming that this value points to the address of the file plus the value. Moving several bytes (up to the large block of zeros) starting here one byte back (and adding a zero at the end to compensate) did indeed cause palette distortion. However, simply changing this value to 0095 has a different effect.
Note that the first file is outside of the first megabyte, so editing the files won't affect the CRC. (Woot.)
Partial list of files:
7FA3C0: 'Player Select'
7FAFC0: ?
7FB8C0: DK's name on player select
Viewing the first file's general area in Tile Molestor produced no real interesting results, suggesting that compression may be used. However, it is interesting to note large holes in the image that correspond to large blocks of zeros. All TKMK files appear to be padded to a multiple of 256 bytes.
On another interesting note, 'JGIN' can be found at 201860, 202981, 2038C0, 209034, 230F48, and 24CFBF. Note that 2 of these are at an odd-numbered address. They are all likely within compressed MIO0 data. They probably don't mean anything special, but treating them as a float, double or R4300 instruction produces nothing interesting (the values surrounding them don't look like code), so I dunno what they are.
Track geometry:
88FA10 is the level data for Mario Raceway. Although the file is only 0x96F4 bytes, there is uncompressed data following it which seems to define the track's geometry. When the last 16 bytes of this were accidentally clipped off, it was obvious that many vertices were being drawn at invalid coordinates (extending infintely into the corner of the screen), and the starting position was far up in the air; most likely at Y-coordinate zero. The race consisted of players falling through the track and the screen blanking out.
Like Mario 64, there are two pointers; one seems to not really do anything, and one defines where the data begins. This is found at 122398. Immediately after it is the pointer to where the data ends, which just happens to be the location of Choco Mountain's data. By changing these two pointers you can move the data around. At 1223B0 is the size of the compressed file. (This seems redundant, but there is uncompressed data after the file, so both are necessary.)
By changing the start and end addresses, moving files around is quite simple. I have moved the data starting at 88FA10 to BF4000 and am tweaking bytes to see what happens:
BFD6F4 [26] -> 20: Deletes all polygons from Mario Raceway!
-> 25: Also deletes the polys, but AI players still race somehow!
-> 27: No visible effect
-> 30: Crash
-> 2C: Crash
-> 28: Crash
-> 1F: Crash
-> 2A: Removes the second fence.
-> FF: Crash
BFD6F5 [1A] -> 18: Transparent parts of fence near giant mushroom turn gray
-> 14: Crash
-> 1C: No visible effect
-> 20: Crash
BFD6F6 [50] -> 58: Fence texture is stretched
BFD6F7 [50] -> 00: Top of fence is just vertical lines
BFD6F8 [20] -> 24: Fence texture is distorted (looks like razor wire)
BFD6F9 [03] -> 04: Changes the fence texture to a grass texture!
-> 02: A different grass texture.
-> 01: A gray gradient. It's half the fence's height, so it repeats.
-> 00: Red and yellow checkerboard wall texture.
-> 05: Striped grass texture from hills.
-> 06: Non-flying flags from the top of the audience stand.
-> 07: Yellow with a brown stripe.
BFD6FA [00] -> 01: No visible effect.
-> 02: No visible effect.
-> 10: No visible effect.
-> 80: No visible effect.
-> FF: No visible effect.
BFD6FB [70] -> 68: No visible effect
-> 78: No visible effect
-> FF: No visible effect
-> 00: Turns the fence into a few pairs of posts, but you still hit where it was.
-> 0C: Same as 00.
-> 30: No visible effect
-> 10: No visible effect
-> 0E: Same as 00.
-> 0F: Same as 00.
BFD6FC [3E] -> 3C: Perhaps the most interesting 'mangling' effect yet. Only the last rectangle
is affected. Rather than connecting to the rectangle next to it, it
connects (perfectly) to the leftmost rectangle of the other fence. This is
also rather amusing as it stretches right across the track at the giant
mushroom. AI characters will smack into it if they are on the screen, but if
they're not, they just casually drive on through. Even when they are, they
occasionally pass through it. You can get past by driving up the hill or by
going between the mushroom and the wall. This could make for some interesting
VS matches against people who can't figure out how to get around it.
-> 3D: Same as 3C, but only one polygon is affected, and it connects to a different
point on the other fence. Almost no hit detection. If BFD6FD is also changed
to FF, it creates a 'second floor' in the pipe; the fence is perfectly level
and spans most of the inside of the pipe, and you can stand on it.
-> 20: Crash.
-> 2A: Crash.
-> 3F: No visible effect.
-> 40: No visible effect.
-> 44: No visible effect.
-> 50: No visible effect.
-> 80: Crash.
-> 3B: Same as 3C.
-> 37: Similar to 3C.
BFD6FD [00] -> 01: Produces a very mangled fence. Notable is one polygon which stretches through
the giant mushroom - it connects to another fence, and you can hop up on it
and drive right through the (solid!) hill to this other fence! This is
especially odd, because with all other "stretch to way the hell over here"
effects so far, only a small part of the stretched polygon had any hit
detection, whereas with this, the entire thing remains solid.
-> 02: Different mangling effect. Again, one polygon stretches to another fence.
However, it's upright, so you can't drive on it.
-> FF: Moves the fence into the giant pipe.
BFD6FE [00] -> 01: The entire fence is now smashed onto one end of the giant pipe! O_o
-> 02: Pieces of the fence cover pieces of the pipe, near the top.
BFD6FF [58] -> 54: Crash
-> 5C: Crash
-> 59: Crash
-> 57: Crash
-> 20: Crash
BFD700 [20] -> 24: Fence is missing a polygon
-> 1C: One of fence's polygons stretches to edge of track. (Note: The fence
polygons are only visible from one side; try using levitation cheats.)
Interestingly, changing it to 24, you can drive through the spot where it
used to be. However, changing it to 1C, you go right through the part that's
stretched out.
-> 1E: Stretches to same place but lower into ground
-> 1F: Pretty much same as 1E
BFD701 [08] -> 0C: Fence has a dent in it and is misaligned a bit
-> 04: Fence is missing a polygon
-> 09: Fence has a stretched polygon, hit detection does kinda work (levitate onto it; you'll slide off)
-> 07: Poly stretches to edge of track, hit detection works near rest of fence
BFD702 [40] -> 48: Different fence poly stretches
-> 38: Stretches to edge of track
-> 41: Dent at bottom - note how this modifies two polygons. The fence is probably
drawn as a rectangle strip (as OpenGL calls it). By the looks of it, if you
try to extend any point into the ground, it's considered invalid and/or
confuses the system, and makes it stretch to a wall at the edge of the
track. Notice that when you do this, the part next to it turns from a
rectangle to a triangle. It's also possible that the game is generating
smaller triangles from the data given here.
BFD703 [0C] -> 0D: One of the points of one of the fence's triangles is moved. What's
interesting is that this point is supposed to touch the top left point of
the triangle beside it, but instead touches the top left point of a
different triangle. This byte may specify a triangle that it connects to.
-> 0B: Stretches to the wall again. This is further evidence of this theory; any
time one of these bytes is given a value lower than it originally was, it
stretches to either a specific point on the wall or one slightly below it.
The game may be realizing that the value is too low to be specifying a valid
point, and instead choosing another, which is at the wall. Notice that the
point on the wall appears to be the place where two sections of wall join.
-> 08: Seems to disappear entirely; others are misaligned. Not sure what to make of
this.
-> 00: Also disappears. Perhaps it's gone underground; viewing in wireframe mode
doesn't support this theory though. (Wireframe mode does, however, have some
bugs; a gray line always extends to the corner of the screen, indicating an
invalid vertex coordinate, and the background colour is whatever colour your
position indicator is.)
BFD704 [58] -> 5C: Crash
-> 54: Crash
BFD705 [A4] -> A0: One of the fence polygons disappears.
-> A8: Same as A0.
BFD706 [18] -> 14: Same as BFD705->A0.
-> 19: Same as 14.
BFD707 [C4] -> C0: One of the fence polys connects to the wrong point on the poly next to it.
-> C8: ...on the wrong polygon. (Like C0 but rotated 180 degrees.)
-> C3: ...a few polygons over.
-> C5: Makes a dent at the top. (Seems to connect to the wrong point; pulls down the
poly it connects to.)
-> C6: Removes the polygon.
BFD708 [1C] -> 1E: Connects it to the wall, though I don't think this is the same wall point it
usually connects to.
-> 1A: Similar to 1E, though it looks like a different point is being connected to
the wall.
-> 1B: Similar to 1A, but connects to a different part of the wall.
-> 1D: Similar to 1E, but looks like yet another different point is being connected
to the wall.
BFD709 [58] -> 54: Distorts and corrupts the fuck out of everything! Graphics are destroyed, AI
characters drive into the wall, every object near the beginning is in a
straight line, karts on the map fly all over the screen, and several polygons
lose their solidity or disappear entirely. If you go too far you simply fall.
Not all of the track is even loaded, and the camera starts way underground.
It seems to be causing memory corruption; the game crashes if you hang around
the AI characters too long, and will be unable to load another track (even
the same one). Laps aren't counted either. (The entire path defining where
you're supposed to go seems to be corrupt, explaining AI driving into walls.)
-> 5C: More corruption. This time the camera starts way up in the air, a bit more of
the track can be accessed, and laps are counted. The AI drives around
randomly instead of just into a wall.
-> 59: Same as 5C. This may be a pointer, but probably not, since it's not aligned.
(The previous byte causes no such corruption either.)
-> 20: Crash.
Interesting note: BFD6FF is also 58, and changing it causes crashing.
BFD70A [28] -> 2C: One of the fence polygons stretches into a SHOT sign, near where others
stretch into the wall.
BFD70C [48] -> 40: One of the fence polygons connects to the wrong point. It's visible from the
back of the fence rather than the front this time.
BFD70D [2D] -> 30: One of the second fence polygons stretches out to a SHOT sign.
BFD70E [2A] -> 26: No visible effect.
-> 2E: No visible effect.
-> 00: Crash.
-> FF: Crash.
-> 30: Crash.
BFD70F [26] -> 20: Removes all polygons.
-> 2A: Removes the first fence.
-> 28: Crash.
BFD710 [1A] -> 1F: Messes up the colours of the first fence. (Transparent parts turn gray, most
gray parts turn transparent.)
BFD72A [2B] -> 20: Crash.
BFD74B [26] -> FF: Crash.
BFE0C6 [2B] -> 20: Completely fucks up everything. Nearly all polygons that aren't part of the
track disappear. Random polygons with track textures appear and disappear as
you drive; some are solid, others aren't. Polygons that remain are textured
like pieces of track. Very trippy and very confusing.
-> 26: Similar to 20. Less confusing as things don't appear and disappear as often,
but the black polygons that just cover large parts of the screen in certain
areas make it difficult.
8FE658 [58] -> 54: AGAIN same as BFF9F6->20, but with the added effect of removing nearly all
polygons. The track is intact but all other ground is gone. There's nothing
left but some chunks of fence, sign posts, walls and that big pipe. It's
fairly neat and quite difficult.
BFF6A6 [26] -> 20: Same as BFF9F6->20, but also fucks up the loading. Between the giant
mushroom and the pipe, the ground around the track actually disappears as you
approach it. It's not just invisible; you can actually fall in.
BFF952 [26] -> 20: Same as BFF9F6->20.
BFF9F6 [26] -> 20: Stretches the leftmost rectangle of the second fence waaaaaay out to
nowhere. You can drive on it; it looks as if there may be an end (it gets
thinner) but I haven't managed to reach any. Does provide a bit of a shortcut
through the mountain though. This is the last instance of 261A in the file, which makes me wonder just how much of it is fence-related... Maybe 261A is a
command that deals specifically with fences, but when why is it scattered
throughout the data?
BFFAF0 [FF] -> FE: Everyone starts way up in the air, no hit detection, and a HUGE polygon
(looks like part of a fence) is stretched out to nowhere. When adding FF
after it, everything is normal; FF is probably an end command.
-> 00: When adding FF after it, nearly the same as with FE. 00 may be some form of
command setting start positions and the like.
This looks a lot like Mario 64's script system. The very first bytes are 26 1A. Exactly 1A bytes from the 1A is another 26 1A. Changing either 26 to 20 removes all the polygons, changing them to 2A removes the object, and changing them to other things usually causes crashes. Only thing that bugs me is that changing the 1A usually just messes up colours... It's possible that the 1A is not a length byte at all, and the fact that the commands are 1A bytes apart is a coincidence. (Actually, Mario 64 counts the command #, so they would be 1B bytes apart.) Mario 64's polygon-related commands have no length byte. Also note the syntax of Mario's texture-loading command:
F3 ss st tt nn hh hw ww
s = s coord of texture
t = t coord of texture
n = tile #
h = texture height
w = texture width
This corresponds well with the data found at BFD6F4:
F3 ss st tt nn hh hw ww
26 1A 50 50 20 03 00 70
Changing the 26 messes up a lot of things, such as removing the object or removing all polys.
Changing the 1A, either 50, or the 20 messes up the textures.
The 03 is where it changes; it's possible that this game has changed the specifications. 03 here chooses which texture to use. The 00 doesn't seem to do anything. The 70, however, does mess up textures. It could also be simply that I've mis-interpreted the specification or it's been mis-documented. If the specification is the same, then the 3E that follows this must be another command number. Changing it to 20 crashes the game, rather than simply removing all polygons; 2A also crashes instead of removing the object. This could simply be because a texture has been defined for polygons that don't exist, or this game adds more bytes to this command (and the 3E is still part of this texture-related command).
It certainly looks like the 3E might be beginning of a polygon-related command, if not polygon data itself. Changing it and the few bytes after it messes up the polygons, connecting them to the other fence or the walls, sticking them in or on the giant pipe, or just moving them around. It would make sense that the game may have combined the texture preparation command with the polygon-drawing command, since you're usually going to be doing both at the same time. (There of course are probably commands that only load textures and only draw polygons.)
Caveat: If the 3E is a command number, then the commands cannot have a length byte, as the next 2 bytes are 0.
Another argument against length bytes: 261A appears at BFD74B, and 16 (hex) bytes later at BFD761. This also shows that most likely no polygon-drawing command is required after a 261A, although 703A is present between them.
Got to figure out exactly how vertices are defined... none of this looks like coordinates. Those may be defined in the MIO0 file. Moving that around's gonna be a pain, though - I have to pad the output, insert it, insert the uncompressed data after it, and update both header fields. 
I wonder if 26 might just be referencing existing structures or some such, and 1A chooses one? Given that all vertex position changes I've managed so far either connect things to other points or extend them way out to nowhere, it seems as though the track has some sort of skeleton. It defines where each point is, then the vertices just define which points they connect to. Though I can't think of any advantage over just defining the vertex coords (maybe it makes hit detection and/or rank tracking easier?), and a few changes go against this, such as those that create 'dents' in the fences - why would one of the points be in the middle of the joint between two pieces of fence? Nothing connects there. It almost looks like the polygons are both connecting to the ground, and this is creating an illusion, making them look like they're connected higher up; this certainly doesn't seem to be it though. I'm not even sure it's possible.
Bah. The compressor still has some bug in it and hell if I'm fixing that now.
BTW, some screenshots of those distortion effects:
(edited by HyperMackerel on 03-05-06 05:50 AM)
|
| 
Hacking Mario Kart 64? That's incredible! One question, how long did it take you to do this? Because wow. Just. Wow.
)
