 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,435,748 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-19-24 12:06 PM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 2 guests |
| Main - ROM Hacking - F-Zero? | New thread | New reply |
| smkdan |
| ||
 Ninji Level: 36 Posts: 24/238 EXP: 288486 Next: 19624 Since: 05-26-07 Last post: 4055 days Last view: 4004 days |
Anyone got data on it? I'd really like to find out some more about the track format in particular, but anything would be nice. I still have to have a more indepth look at the track formulas but I can say a few things about it. Here's what I've published for now. It's much better than having random notes scribbled in a .txt
http://smkdan.eludevisibility.org/fzero.html |
| Heian |
| ||
 Red Koopa Level: 27 Posts: 65/126 EXP: 111827 Next: 4332 Since: 03-08-07 Last post: 5840 days Last view: 5839 days |
A bunch of people here spent a lot of tine trying to hack F-Zero, and we never got anything done. One problem was the big precomposed 32x32 "panels" -- they have to be lined up just right for the tracks to be drivable, so while it's possible to spot the layouts of those panels in the ROM (Death Wind's is particularly noticeable if you set your hex editor to 32 bytes per line; an oval of numbers in a sea of 00 bytes!),
I actually managed to make an alternative Death Wind, but if you drive into certain areas, it becomes a farce as your car gets pulled every which way while the computer tries to get you on to a pre-determined path. The only other accomplishments I had were to make a new font for the times, which looked more like the font used for the speed, and to make a new Big Blue background which looks more tropical. I can't run this on the computer (Mac!) I'm in front of now, so I can't vouch for its completeness, but on my web site I spotted an attempt at new graphics on Silence and putting the tile numbers over the graphics in order to get a handle on the course layouts. These two files might also contain the tropical Big Blue; I'm not sure. The GBA F-Zero games have a slightly different panel structure. I think they're made of 8x8 tiles, the layout of which is then compressed. Perfect Guy, if he's still around here, decrypted this layout, but due to the fact that each tile has to butt against each neighbor in three or four exact ways (vertical and horizontal position of the round "barrier" circles, which side of the barrier the course is on, and then the position of the under-track shadow), making new panel layouts is extremely difficult. As a last resort, I looked into taking the 256 pre-composed panels in Climax, which are pre-built to fit with each other, and making 256 new and more interesting ones. I couldn't find where in the game they were stored, and eventually went back to hacking baseball games (^^  .
Your work on the original F-Zero looks great, though! Maybe we can have another go at it! |
| GuyPerfect |
| ||
 Paratroopa Level: 30 Posts: 62/155 EXP: 152515 Next: 13354 Since: 03-14-07 Last post: 6038 days Last view: 5987 days |
Check your PMs, Heian. I sent you a message before you made that post.
And yeah, I've done my fair amount of F-Zero-related hacking. Hacked Maximum Velocity and the SNES one (but only a bit), and made a level editor for F-Zero X. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 25/238 EXP: 288486 Next: 19624 Since: 05-26-07 Last post: 4055 days Last view: 4004 days |
Thanks for the lengthy reply. I gave that idea a shot and it worked pretty well actually.
I never thought of doing that...Well, it looks my confusion about sharing tracks is over. You even see bits of the other track in-game if you go right to the edge. It's easy to pick out the tracks on all except ones that have more complex non - driveable areas like Whiteland. You say you made an alternative Death Wind but the computer wouldn't let you get by? How did it do that? Was it like the anti-shortcut thing on Port Town that takes you back to a particular spot if you try to jump the track? 32x32 panels...that sounds about right. You mean each byte in that 512byte table refers to a panel right? That makes the track at most 8192 pixels tall and 4096 pixels wide. The way I'm seeing it is that the game stores different panels for each track set (7F:5000-7F:FFFF), and these panels are constructed out of smaller, simpler panels (7F:0000-7F:24FF shared globally). I tried those patches on my (J) and (U) ROMs but I can't notice any difference in game. I stripped the header but that causes it to not start up at all. Is it suppose to have that wierd 3.92MB filesize after the patch? |
| GuyPerfect |
| ||
|
Paratroopa Level: 30 Posts: 64/155 EXP: 152515 Next: 13354 Since: 03-14-07 Last post: 6038 days Last view: 5987 days |
If it's anything like the GBA games, there's a predefined path that all machines are expected to adhere to. Just a list of points that draw the path that machines are supposed to take. The GBA games allow parts where there are two alternate paths, which helps with forks in the road as well as having the CPU players use the pit area.
There's a special tile used in the panels of the track, usually tile 00, that represents "nothing here" and allows the course "floor" to show through. Of course, the SNES game has the ground built into the panels themselves, so it's probably a bit different. Either way... As a machine glides across the course, it travels over each of the path points, in order. That's how the game knows when you're facing the wrong way, etc. When you drive on a tile on a panel that you're not supposed to drive on, the game says "OMFG Collision!" and pushes the machine back towards the path point they're supposed to be on while administering a little damage. If you modify the track but not the path, you have to be very careful not to step in the wrong spot. If you do, it'll painfully drag you across the netherworld until it puts you back where it thinks you're supposed to be, which may very well be in the middle of nothingness itself, causing your machine to blow up. On a side note, if you're airborne and you land on one of those "nothingness" tiles, you blow up. That's how the game detects a miss. |
| Heian |
| ||
|
Red Koopa Level: 27 Posts: 67/126 EXP: 111827 Next: 4332 Since: 03-08-07 Last post: 5840 days Last view: 5839 days |
Sorry about those patches not working -- but I can give you a bit of the falvor of those hacks by posting some ancient screenshots that I dug up (and please forgive the ugly white borders on the older ones):
* Before we found that 'panel map' with a the 00s to denote empty space, we had found an area that seemed to be track layout. These bytes actually define the larger panels. IIRC, two bytes correspond to a 32x2 strip of small 8x8 tiles. We were able to bridge Sand Ocean and Silence by making a row of blank track tiles: 
* Then, while we were tring in vain to make new courses, I had a go at making new backgrounds and fonts. Here's the new, more tropical, shallower Big Blue: 
(The font used for the time now looks like a taller version of the one used for the speed. Now I can't look at the original anymore. ^^) * Next up was to make Silence into Stonehenge. Would be a nice twilight scene but you have to pretend not to notice that the moon is immense, and the grass is 'flowing'.  ;
* I also managed to turn Port Town into a daytime scene with white clouds and green mountains. It's supposed to be the Arashiyama area of Kyoto: 
This is the game's title screen, so it really makes things look different. I was in the middle of making Fire Field into a dull gray moonscape when the project sort of drifted away. I still think a great F-Zero hack could be made if we could just get around this compression, and somehow give the user the ability to draw new 'panels' first before laying them out. When Nintendo made BS F-Zero 2, the panel maps are (IIRC) kept intact; what's different is the layout of the tiles that form these panels. Even if we could only make new panels, it would still feel like a new game One possibility is to take the 256 pre-made panels in F-Zero Climax, which the game has already prepared algorithms for computer cars to drive on, and redraw some of the redundant ones and make more interesting ones. Unfortunately I could never find any data about them in the Climax ROM. Guy Perfect, you wouldn't happen to know anything about that data, would you? ^^; GP Legend probably also has the ability to do this -- the mythical eReader cards seem to be formed by these same panels that are used in the Climax course editor. Climax has 16 different areas each with their own tile graphics, and plenty of tunes, cars, etc., so we could probably get some serious variety going on if we edited that game. |
| GuyPerfect |
| ||
|
Paratroopa Level: 30 Posts: 66/155 EXP: 152515 Next: 13354 Since: 03-14-07 Last post: 6038 days Last view: 5987 days |
I've only worked with Maximum Velocity on GBA. Sorry.
However, I am at this time working with smkdan. We should start diving into hacking full-speed here fairly quickly, then we'll have a good chunk of stuff to update. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 26/238 EXP: 288486 Next: 19624 Since: 05-26-07 Last post: 4055 days Last view: 4004 days |
You mentioned 32x2 tiles, which is true for part of it. The game is loading an array of 2x2 tiles for every 2 bytes in the deepest part of the panel map.
Table #2 on my site has entries, which when indexed by the Y posiiton, point to a row of tiles on table #3. It's effectively a row selector. Table #3 (indexed by the X position much like table #2 does for Y) points to the tile pool (0000-24FF), of which it then pulls 2x2 tiles, and proceeds (up to 16 times) until the buffers to VRAM are filled or until the byte index overflows from 32 of which it then moves onto the next panel and reloads the pointers. So..every entry in table #2 corresponds to 32x2 tiles, and every entry in table #3 corresponds to 2x2 tiles. That explains the huge size difference, and why Nintendo used a bit of compression there. |
| Heian |
| ||
|
Red Koopa Level: 27 Posts: 68/126 EXP: 111827 Next: 4332 Since: 03-08-07 Last post: 5840 days Last view: 5839 days |
Just thought of something -- there was once a great site where someone had all the Mute City 1 panels saved as graphics, and you could enter the numbers of the panels and it would display them for you. I can't seem to find it anymore but I saved one example of the giant map that it output for you and can upload it somewhere if you want to see it.
One thing that proved to be difficult was editing the names of the tracks. Sounds like something that would be trivial to find, but it wasn't. Also, no one ever found any data about the speeds of the cars. It would be nice to restore some balance by giving the non-Fire Stingray cars a little more speed. (I got the graphics from one of the BS F-Zero 2 cars into the regular game, but they were glitchy, the palette was off, and in any case the stats didn't change.) You two know a lot more than I do about the programming aspect, but I could probably still make aesthetic adjustments like new backgrounds, etc. A lot of the background graphics are repeated and there isn't much space to make new stuff like there would be with Climax or GPL. SMKdan, did you actually figure out what the compression is? Years ago, we were unable to discover what the relationship between the two-byte compressed value and the raw tile numbers was. Guy got it for MV; it was something that hadn't been used in other games (and was in fact very difficult to convert into -- my tracks were full of glitches). I suspect that with some flexible 32x32 panels that can connect with various things, we could make some really good courses just by taking advantage of the course-specific panels. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 27/238 EXP: 288486 Next: 19624 Since: 05-26-07 Last post: 4055 days Last view: 4004 days |
Did that site have any documentation? Would also be nice to have something to compare to when generating panels from collected notes.
Sounds like a first thing to try, but did you try a search relative for those names? I think I got a solid handle on the track format. The track data for table #3 itself is compressed. The highest 2 bits provide a portion of another pointer. These byte pairs a shifted down with the AA - FF bits ending up creating another byte pair. XXXXXXXXXXXXXX88 XXXXXXXXXXXXXX99 ... XXXXXXXXXXXXXXFF Then, it writes these 2 bytes in the next spot. FFEEDDCCBBAA9988 Every 16 bytes in ROM yeilds 18 bytes in RAM. Only 14 bits are required to index the whole tile pool (0000-24FF). FF up there obviously isn't used. To expand on the previous post, I'm pretty confident on the track format it's using. Every 32x32 panel has: 16 2byte entries for every set of 32x2 rows in the panel (Table #2) Each row has 16 2byte entries which point to the tilepool arrays. Each entry represents 2x2 tiles (Table #3) Each panel therefore has 256 (16x16, since each entry in table #3 represents 2x2 tiles) 2byte entries total which point to the tilepool arrays The upside of doing it this way means 32x2 rows can be reused many times. The tilepool represents 2x2 tiles; this is because the buffers represent 128x2 tilemap bytes. The game runs through a loop reading the 2x2 tiles from the tilepool 64 times to fill the 128x2 tilemap buffer entirely. The tilepool 2x2 tiles are arranged in a way where Byte1: Top left corner Byte2: Bottom left corner Byte3: Top right corner Byte4: Bottom right corner -- Yeah, physics would be nice. I'd like to get Green Amazone in there since it had really nice drift physics, but only one track with corners to use it. Guy, I think we have enough to start really getting into it. I've looked at the horizontal and vertical updaters and they all show code which fits right into the format I describe. All the Track, conditional track modifiers and pointers are all sorted. |
| GuyPerfect |
| ||
|
Paratroopa Level: 30 Posts: 68/155 EXP: 152515 Next: 13354 Since: 03-14-07 Last post: 6038 days Last view: 5987 days |
Wonderful. I'll take another shot at the path format shortly.
For everyone else, what I found with the path was for a North American ROM with a 512-byte header. I was able to screw up the AI on Mute City, but I haven't cracked the data just yet. It's not plain simple as would be nice. (-: Setting all bytes from 176A0 to 176B0 to the value 00 makes the AI immediately veer off the right side of the track. Anyways, I'll do more work on it and see what I can find. It might be compressed, but the data surrounding it suggests otherwise... But still! (Man, I hope it's not compressed. There has yet to be an F-Zero game I've worked with that I didn't have to crack a compression format) __________ EDIT: Wait a sec... I don't see that PM in my sent list... smkdan, did you get a message regaring the path info or did it get lost? |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 28/238 EXP: 288486 Next: 19624 Since: 05-26-07 Last post: 4055 days Last view: 4004 days |
I don't have anything new my PM box; must've got lost.
Nice work. Paths really need to get sorted because reverse detection, arrow boost function and your only competition rely on it. I hope they all rely on the same set of values anyway. |
| GuyPerfect |
| ||
|
Paratroopa Level: 30 Posts: 69/155 EXP: 152515 Next: 13354 Since: 03-14-07 Last post: 6038 days Last view: 5987 days |
Messing up the data I described will mess up computer AI as well as "reverse" detection. The only thing that doesn't seem to line up right now (I might just not know the details yet) is the exact coordinates of the starting position, which appear to be independent from the course path.
Another note of interest is that the four usable machines need a good stretch of straight road to drive on right at the start. They drive straight for a few seconds before shifting over to conform with the course path, which means you can't have a curve right after the lap line. Other than that, there don't appear to be any restriction in what can be done with the path. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 29/238 EXP: 288486 Next: 19624 Since: 05-26-07 Last post: 4055 days Last view: 4004 days |
Here's the start coordinates from one of my logs. Again, they're headerless. 2 Bytes each. I noticed changing the AI in those ranges breaks collision for your car, and changing these also breaks the collision...
X, Y BigBlue: 16005, 16007 Sand Ocean: 1600F, 16011 Silence: 16019, 1601B Port Town1: 1602C, 1602E Port Town2: 1603F, 16041 DeathWind1: 16049, 1604B DeathWind2: 16053, 1655 Red Canyon1: 1606F, 16071 Red Canyon2: 16082, 16084 Fire Field: 1608C, 1608E MuteCity1: 1609F, 160A1 MuteCity2: 160BB, 160BD MuteCity3: 160E0, 160E2 WhiteLand2: 160EA, 160EC WhiteLand1: 160F4, 160F6 |
| GuyPerfect |
| ||
|
Paratroopa Level: 30 Posts: 70/155 EXP: 152515 Next: 13354 Since: 03-14-07 Last post: 6038 days Last view: 5987 days |
I think, at least in part, that the path data is built relative off of itself, which would explain the collision botching. However, regardless of where the start position is or what you do to the first half of the path data, the second half of the lap is always navigable by the AI.
I'm learning slowly, but still don't know enough to decode the path data. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 30/238 EXP: 288486 Next: 19624 Since: 05-26-07 Last post: 4055 days Last view: 4004 days |
You're right Guy? (if i may toss in my 2c, this anonymous crap is beyond retarded). Before the AI data is stored into RAM, it adds the previous 16bits that came before it, or in the case of the very first entry, the starting coordinate. |
| GuyPerfect |
| ||
|
Paratroopa Level: 30 Posts: 72/155 EXP: 152515 Next: 13354 Since: 03-14-07 Last post: 6038 days Last view: 5987 days |
Long story short, I think I got it. Picture!
Mute City I appears to have a list of 29 X values followed 29 Y values. Each value is biased by the one preceeding it. They're 16-bit signed integers; little endian. IMPORTANT: The first entry in the list is in fact the first point of the path data. However, the first point is not on the lap line. Its values are biased by the lap line, but the first point in the path is actually a bit ahead of the starting point. __________ Now comes the big question... Why 29? Is it 29 for all courses? I'm guessing probably not. smkdan, your knowledge could come in handy here. See if you can find out exactly where the number of points comes from. __________ EDIT: After some further examination, I can see that my data isn't quite right. But hey, I'm a lot closer than I have been. |
| VL-Tone |
| ||
 Micro-Goomba Level: 10 Posts: 2/12 EXP: 3290 Next: 1124 Since: 02-22-07 Last post: 6095 days Last view: 5660 days |
I did a lot of F-Zero Hacking back in the days, just before I got sucked into SM64 hacking...
I managed to completely decode all tracks at the time, and was working on the AI data.       
Higher resolution maps (2048x1024) can be downloaded there: http://homepage.mac.com/qubedstudios/F-ZeroMaps.zip I remember doing full res maps, but I can't find them... This is the old archived thread: http://acmlm.no-ip.org/archive2/thread.php?id=821 My English improved a little bit since then 
I dug a few things that might help you with A.I. hacking:
Heian-794 asked me:
My answer was:
Sorry for the long post, but I don't have time to trim it down... |
| GuyPerfect |
| ||
|
Paratroopa Level: 30 Posts: 73/155 EXP: 152515 Next: 13354 Since: 03-14-07 Last post: 6038 days Last view: 5987 days |
Thanks for the bit of insight, VL-Tone.
I'm at a loss as to the reasoning behind the "low order byte inverted" business, but it DOES seem to get the job done. 
This was generated from data at 0x176A2 on a 512-byte headered ROM and extracted as thus: 16-bit unsigned integers, little endian, low-order byte inverted. If the bytes read from ROM are in order and are B1 and B2, then the value is B2 * 256 Or Not B1. For Mute City I, there appear to be 29 points (1D, not 3A), and are stored as "all X's first, then all Y's." __________ This data is all shifted a bit to the right and a bit forward from where the official starting point is and I don't know why. If the AI likes it, I guess that's okay. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 31/238 EXP: 288486 Next: 19624 Since: 05-26-07 Last post: 4055 days Last view: 4004 days |
Awesome post VL-Tone. Never noticed a thread in the archives...
A few more notes: -X coordinate AI begins at 7E:11FE in RAM -Y coordinate AI begins at 7E:13FE in RAM (I'm not sure how you got that address, VL-Tone) The above 2 addresses hold their respective starting coordinates. Loaded AI that's been operated upon is stored at 7E:1200 and 7E:1400 respectively. The AI points seem to be portioned into 2 parts... Length counters are stored as 1byte value. It's the high byte of a 16bit value where I'm not so sure of what it's doing to the other byte. For mute city 1 it's stored at 1609D (1700h) for the first, and 160A6 for the second (0600). That makes for 17h + 6 = 29 X and Y coords. Looks like you got it right. It carries on from where it left off. Nice to see people really getting into this. Might be closer than ever to getting it sorted. EDIT: Forgot to mention, AI for Mute City runs from Part one (17h) 174A3 - 174BA X 174DE - 174F5 Y Between transitions it loads these 16bit X and Y values and sticks them in the next spot. 160A8 X 160AA Y And this carries right on. Part two (06h) 17695 - 1769B X 1769C - 176A2 Y So, it's actually 30 points in Mute City 1 if you count the 'middle values' up there. |
| Main - ROM Hacking - F-Zero? | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 132, rows: 171/172, time: 0.019 seconds. |
