 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,488,044 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-26-24 02:50 PM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 2 guests |
| Main - ROM Hacking - Looking for Super Mario Kart data | New thread | New reply |
| Stifu |
| ||
 Cobrat Level: 56 Posts: 103/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
To sum things up, I need the following data for my SMK track editor, which I must finish before the 6th of June (not the final version, but a nice enough version for my university presentation)...
Data needed: - The pointers that define what's the type of each tile (road, grass, water/mud, obstacle...) - The pointers that define which color palette is applied to each tile - The track object layers (which includes option blocks, coins, pipes and the likes) Has anyone found any of that ? That'd help. |
| MathOnNapkins |
| ||
 Super Koopa Level: 62 Posts: 141/842 EXP: 1935534 Next: 49152 Since: 02-19-07 From: durff Last post: 4488 days Last view: 4011 days |
Right now I'm really tired but tomorrow I might be bored enough to find some of that. Color palette seems like the easiest to find, then objects, then tile types. ____________________ Zelda Hacking Forum hobbies: delectatio morosa |
| smkdan |
| ||
 Ninji Level: 36 Posts: 1/238 EXP: 288653 Next: 19457 Since: 05-26-07 Last post: 4063 days Last view: 4012 days |
Here's a few quick observations.
The upper bits that are OR'd with the 4pp tiles to get your 256 colour tile are stored at 7F:C000-7F:C0FF after they're pulled from ROM. They only have the upper 4 bits set ofcourse. $8481CA holds the upper 4 bits that are ORd with the 4bpp tile 00. (SNES address or 481CA ROM address). According to your doc this lands it in the mariocircuit GFX area. I changed 481CA to 10 and it turned tile 00 to orange. The SMK palette page shows orange just below the grass colours so it makes sense I suppose. I changed the next byte that didn't destroy the track entirely (481CD) and it changed alot of tiles to the orange palette. 481CC seems to hold the value it repeats for (41h + 1 = 66 tiles), they're mostly track / sand tiles. 
oh and goodluck with that editor. |
| Stifu |
| ||
|
Cobrat Level: 56 Posts: 104/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
Thanks for the replies.
That'd be cool, MathOnNapkins... Maybe using my notes as smkdan did could help you find stuff more easily (although I need to udpate them with the AI data and all). By the way, smkdan, I'm a hacking noob, so I have no idea what "OR'd" stands for... But in other words, the palettes applied to each tile would be defined in the same blocks as the road graphics for each track, right ? Hmmm, did you change those palette pointers after having decompressed the block, or just like that ? If it's the latter, that'd explain why some of the stuff you tried messed up the whole track. |
| NetSplit |
| ||
|
Level: 32 Posts: 13/178 EXP: 188034 Next: 18408 Since: 02-26-07 Last post: 2217 days Last view: 2142 days |
OR is a logical operation. When you OR two numbers, you go bit-by-bit, checking to see if the bit is 1 for either of the two numbers. If either or both are 1, then the resulting bit is 1. If neither are 1, then the resulting bit is 0. So, for example:
26 OR 93 = B7 ie 00100110 (26) OR 10010011 (93) = 10110111 (B7) Even simpler: 0 OR 0 = 0 1 OR 0 = 1 0 OR 1 = 1 1 OR 1 = 1 By ORing two bytes together, you can combine things that contain different bits of a number you want. For example, if one byte has the 4 high bits and the other byte has the low 4 bits, OR them together and you get a byte with all 8 bits (assuming the unused bits are all 0). Hope that helps. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 2/238 EXP: 288653 Next: 19457 Since: 05-26-07 Last post: 4063 days Last view: 4012 days |
I just remembered. When I decompressed some track graphics I noticed there were some dummy tiles right at the start. 256 bytes; thats 8 4bpp tiles or 4 8bpp tiles. There's your palette bytes right there.
So yeah, they're stored at the start of each compressed hunk of track graphics, in just the same format. I don't know much about the compression format it actually uses. I don't rmemeber seeing any documentation in the lunar compress zip. |
| Stifu |
| ||
|
Cobrat Level: 56 Posts: 106/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
Thanks, smkdan. I'll manage from that. It's probably the same compression format used in the vast majority of the ROM.
And thanks for the explanation, NetSplit, that's a bit clearer... |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 3/238 EXP: 288653 Next: 19457 Since: 05-26-07 Last post: 4063 days Last view: 4012 days |
No worries.
Speaking of palette pointers, I have the 24-bit pointers that point to the actual palettes themselves. Stifu, this might be a good addition to your compilation since modifying these with an expanded ROM means no real size restrictions. They start at 0x1EDB8 for a headered ROM and span 3 bytes for each track ofcourse (the first is for Rainbow Road). Say for Mario Circuit... IE: 1EBBE: 11 1EBBF: 7F 1EBC0: C4 C4:7F11 SNES perspective / 47F11 ROM. You can just stick your oversize palette in the end of the ROM space that TrackDes probably won't use, or you can just expand the ROM yourself. |
| Stifu |
| ||
|
Cobrat Level: 56 Posts: 107/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
Posted by smkdan Yeah, I already found that a little while ago, and it's in my updated notes (I update them from time to time, you probably have an earlier version)... However, according to my notes, they start at 0x1EDBB, and the Rainbow Road is the last one (0x1EDD0), not the first one. 0x1EDB8 is for the tile graphics address for the Rainbow Road. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 4/238 EXP: 288653 Next: 19457 Since: 05-26-07 Last post: 4063 days Last view: 4012 days |
I saw different GFX from TT select screen so I thought it was part of the palettes aswell. yeah I got this one from around the earlier part of the year. I'll get myself the updated one. |
| duffjr |
| ||
 Micro-Goomba Level: 11 Posts: 6/16 EXP: 5048 Next: 937 Since: 04-15-07 Last post: 4553 days Last view: 4553 days |
it seems glitchcog knows those locations.
http://www.youtube.com/watch?v=j69kcmPBCJE |
| Stifu |
| ||
|
Cobrat Level: 56 Posts: 109/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
Posted by duffjr That video doesn't prove he knows these locations. You can do everything he did there without having to know the data requested above. |
| Raccoon Sam |
| ||
|
Cobrat Level: 56 Posts: 199/672 EXP: 1380044 Next: 18132 Since: 02-19-07 From: Hi Last post: 3468 days Last view: 2699 days |
My advice would be to look at the tracks and compare them with other tracks with the same tilemap.
Look for everything that they have in common, and try messing around. I guess. ____________________ |
| Stifu |
| ||
|
Cobrat Level: 56 Posts: 110/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
I can't follow your logic... What would I find by comparing tracks that have the same theme ? |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 6/238 EXP: 288653 Next: 19457 Since: 05-26-07 Last post: 4063 days Last view: 4012 days |
what do you mean Raccoon Sam? All the tracks have different tilemaps.
I would really like to find out how the track sprites are stored. It looks hideous having pillars supported nothing, thwomps on lava and pipes and moles in ridiculous places. I found some pipe related data btw. Here are some of the addresses it feeds to the DSP-1 for command #6 (object projection calculation). This is for one of the mario circuit pipes. 2 bytes each. It's what the dev manual says anyway. 7e:1818 = X (7e:1816) 7e:181c = Y (7e:181A) 7e:181f = Z The output X and Y eventually end up in sprite RAM. Bracketed addresses hold data which is used to operate on the X and Y variables. Haven't messed with enough to find what they do. These values initially hold values pulled from the ROM. Changing X and Y to all FF gets this. Z didn't do anything when I messed with it. Seems to be relative to the bottom right... 
I'm off to bed; I'll find more about it later on. |
| Stifu |
| ||
|
Cobrat Level: 56 Posts: 111/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
Thanks for the help, smkdan... Hope you can find more stuff.
I'm currently working hard on getting the track gfx to display... |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 7/238 EXP: 288653 Next: 19457 Since: 05-26-07 Last post: 4063 days Last view: 4012 days |
I can confirm a few object notes. I played with the pipe again today and found the following.
The positions in RAM are relative to the top left, not bottom right. X has a maximum value of 3FF as does Y. 1FF would land it in the middle of the appropriate axis. I did not change the Z paramater but the pipes still bounce karts off it and appear at a proper size. The values I mentioned that operate on it before the DSP-1 does its stuff can be left alone to modify their positions. Here I changed X to 000 and Y to 3FF. As explained, it appears at the very tip of the track. 
X = 3FF Y = 000 
X = 3FF Y = 3FF 
With any luck, the other track objects follow a similar format and you'd have an object relocator included in that editor of yours. Now to find where in ROM they're stored... EDIT: I added one too many F's... |
| Stifu |
| ||
|
Cobrat Level: 56 Posts: 112/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
Nice find.
Considering it shouldn't be much data, I don't think it's compressed in the ROM... Tried looking in the ROM for the exact same values you changed in the RAM ? |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 9/238 EXP: 288653 Next: 19457 Since: 05-26-07 Last post: 4063 days Last view: 4012 days |
If only it was that easy. First thing I tried, then realised the matches didn't turn out to be the pipe data at all. There's some weirdness thrown into the mix.
Here's a snippet. It's storing the X and Y (not the registers) to the mentioned memory locations above. That first line is what it pulls from the ROM. LDA [$08],y[$85:C9C0] PHA AND #$007F ASL A ASL A ASL A ADC $0FC6 [$84:0FC6] STA $18,x [$00:1818] PLA AND #$FF80 LSR A LSR A LSR A LSR A ADC $0FC6 [$84:0FC6] STA $1C,x [$00:181C] I'm not sure if you know 65816 so here's a run down. 7e:0fc6 holds a constant of 4 on all tracks except Donut Plains which holds 10. X = Take 85:C9C0, drop all but the 7 low bits, multiply by 8, add 4 *or* 10. Y = Take 85:C9C0, divide by 16, drop the low 3 bits and add 4 *or* 10 to it. C9C0 spans two bytes ofcourse. No, I don't know why it does this. It just...does. Hey, maybe they wanted to squeeze 4 bytes out of their 2? I hope so, and there isn't something deeper to it. A collection of pipe data is around 85:C9C0 packed cloesly together. Notice how when you move away from a collection of track sprites, they vanish and new ones take their place? They fill up the X and Y object RAM whenever a new section of the track is entered, so it's not all loaded at once. This means that the 'object clusters' need to be accounted for, as only a handful of track sprites will be selected for display at any given time. Oh and yes, the same routine and same format applies to other track sprites aswell. |
| Stifu |
| ||
|
Cobrat Level: 56 Posts: 113/666 EXP: 1361310 Next: 36866 Since: 02-22-07 Last post: 685 days Last view: 307 days |
I'd usually do it the blind stupid way... Replace data in the ROM by 00, and see when it ends up affecting track objects. 
This is all the more doable since there aren't that many data ranges that are still unknown... |
| Main - ROM Hacking - Looking for Super Mario Kart data | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 127, rows: 166/167, time: 0.017 seconds. |