Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Rom Hacking: hukka | 2 guests
Acmlm's Board - I2 Archive - Rom Hacking - Complete F-Zero tracks images (at last!)
  
User name:
Password:
Reply:
 

UserPost
neviksti
Posts: 8/25
Well, it looks like it gets the row data after at least two "unpackings".

- somehow the rows for the "track panels" as you called them (32x32 tiles, or 16 rows) are put into ram
- then the rom data holding all the track panels are unpacked (using the above ram table) into just row data in ram

I have not found that first part yet (or more accurately, I may have found it, but have not made sense of it yet ... it jumps all over).

Here is the routine for the second part:
Notice there is no compression ... so this step is easy.

80/A30D: C230 REP #$30
80/A30F: ADF50C LDA $0CF5 ; ?? track #
80/A312: 29FF00 AND #$00FF
80/A315: 0A ASL A
80/A316: AA TAX ; X = 2 * track #
80/A317: A9000C LDA #$0C00
80/A31A: 8521 STA $21 ; rom source bank: $0C
80/A31C: BF80E80C LDA $0CE880,X
80/A320: 8520 STA $20 ; rom source offset: $0CE880,X
80/A322: A9007F LDA #$7F00
80/A325: 850A STA $0A ; ram source bank: $7F
80/A327: A00000 LDY #$0000
80/A32A: BB TYX ; clear x,y
;"unpack row data" loop
80/A32B: B720 LDA [$20],Y ;get word for rom
80/A32D: F01A BEQ $A349 ; $0000 means done unpacking
80/A32F: 8509 STA $09 ;otherwise rom word = ram source offset
80/A331: 5A PHY
80/A332: A00000 LDY #$0000
80/A335: B709 LDA [$09],Y ;get word from ram
80/A337: 9F00407F STA $7F4000,X ;move to $7F4000 table
80/A33B: E8 INX
80/A33C: E8 INX
80/A33D: C8 INY
80/A33E: C8 INY
80/A33F: C02000 CPY #$0020
80/A342: D0F1 BNE $A335 ;get 16 of these
80/A344: 7A PLY
80/A345: C8 INY
80/A346: C8 INY
80/A347: 80E2 BRA $A32B
80/A349: E210 SEP #$10
80/A34B: A20E LDX #$0E
80/A34D: BD7BA3 LDA $A37B,X ; copy data directly, $10 bytes
80/A350: 9FF03F7F STA $7F3FF0,X ; $00A37B -> $7F3FF0
80/A354: CA DEX
80/A355: CA DEX
80/A356: 10F5 BPL $A34D
80/A358: A212 LDX #$12
80/A35A: BD67A3 LDA $A367,X ; copy data directly, $14 bytes
80/A35D: 9DC00E STA $0EC0,X ; $00A367 -> $7E0EC0
80/A360: CA DEX
80/A361: CA DEX
80/A362: 10F6 BPL $A35A
80/A364: E220 SEP #$20
80/A366: 60 RTS

VL-Tone
Posts: 49/200
Originally posted by neviksti
Hello, I was curious about the F-Zero data and people suggested I look here.

I am by no means a rom hacker, more of a rom programmer I guess. So my main methods for trying to understand a rom are to look at the code. This is usually slow and inefficent, but eventually leads to a fairly complete understanding of what the game is doing during xyz.

In short, I'd like to help... but be patient as my methods are slower.

I figured out how the game keeps track of its state and goes through menus etc. So I tracked down this...

Here is the "grand prix mode" track loading routine:
...

Hopefully this will quicken the search for others reading the code.

I would love to see a fully functional track editor, so if you tell me what is most needed, I can try to focus my efforts on that. In the mean time, I'll continue reading through the code.


Hey welcome here neviksti, great work on the main track loading routine! sorry for the time it took to reply (and sorry to bump the thread). There is nothing wrong about doing ROM hacking by looking at the code "Au contraire" as they say... You'll see that the best ROM hackers here mostly work like that (I'm not one of them), and I wouldn't say my methods are necessarily faster. Though the main reason my hacks/editors don't progress is mostly because I simply don't program/hack much these days, not because I'm slow at it.

I just found a key element that is missing and this is where your help will be needed... I guess it was obvious but I somehow forget to check for that.

Forget about the ZST states adresses, the (W)RAM adresses are much more logical.

Look at these adresses, they are the offsets for each row. To find the offset in the master row data
IN RAM is simply by adding 7F000 to the 16 -bits adress, on the picture the first row data offset is 42767F (reverse byte order). Just read 32 bytes from this address and you get 16 2 bytes offsets. Add $64580 to the offset to get the ROM address (with 512 bytes header) of the 4 bytes data describing a macro-tile (2x2 tiles).

The master row data actually starts at 7F4000 in RAM and not every part of the 7F RAM bank is used for row data. I made a table on the older thread describing what ranges are used.

So the key element I found is a single mention of 00407F in the ROM close to F03F7F which seems to point to a 16 bytes row data "header" in RAM. This is likely part of the row data decompression code. So you mission neviksti, if you accept it, will be to reverse-engineer the row data decompression routine It's not like I couldn't do it myself , and I'm willing to help, but you seem more used to deal with SNES code than me.

So just look at $2536 in the ROM (or search for 00407F) and try to figure out how the routine writes to this address in RAM. But before anything, what we need to know is where this compressed data is read from in ROM, looking at this code around $2536, you should be able to find out.

Once we can compare the compressed to the uncompressed data it can be much easier to figure the inner mechanism.

Note that if you change the 00407F or F03F7F to something else, you'll see that the header and row data are shifted accordingly om RAM. Somehow, the game will read the data at the correct relative address, but the row data can get corrupted by other data written in RAM if you offset it.

Heian-794 Great graphical hacks!! I love Kyoto, I want to move there someday (ok maybe not). A F-Zero track editor should include a graphic editor, though cars are really tough to edit unless you use CGI models like FZ2 and the GBA F-Zero, but for me the hand drawn cars are part of the original F-Zero experience. Still, it could be fun to integrate CGI 3d models
Heian-794
Posts: 713/896
Here are some images from the graphical hack I was working on.

I had this idea of setting the game only on Earth, at the beginning of the F-Zero races (maybe AD 2300 or so). So all the tracks will be based on real places. I made Port Town into a daytime scene in Kyoto, and Silence into Stonehenge in England. Big Blue is now a tropical island in the Pacific:

Image Hosted by ImageShack.us

As for the new Port Town, I can't find any pictures of Arashiyama on my HD, but here's the Uji River which looks similar:

Image Hosted by ImageShack.us

I need to get those futuristic arcology buildings out of there though. I was thinking of glass skyscrapers with traditional Japanese rooves, but I'm not much of a pixel artist...
neviksti
Posts: 1/25
Hello, I was curious about the F-Zero data and people suggested I look here.

I am by no means a rom hacker, more of a rom programmer I guess. So my main methods for trying to understand a rom are to look at the code. This is usually slow and inefficent, but eventually leads to a fairly complete understanding of what the game is doing during xyz.

In short, I'd like to help... but be patient as my methods are slower.

I figured out how the game keeps track of its state and goes through menus etc. So I tracked down this...

Here is the "grand prix mode" track loading routine:
80/88FC:    20D589      JSR $89D5
80/88FF: 20E397 JSR $97E3
80/8902: 20C489 JSR $89C4
80/8905: 207FAB JSR $AB7F
80/8908: A558 LDA $58
80/890A: D006 BNE $8912
80/890C: 20C8B0 JSR $B0C8
80/890F: 2064B1 JSR $B164
80/8912: A901 LDA #$01
80/8914: 8598 STA $98
80/8916: A902 LDA #$02
80/8918: 8581 STA $81
80/891A: A902 LDA #$01
80/891C: 648E STZ $8E
80/891E: 858F STA $8F
80/8920: 207BA2 JSR $A27B
80/8923: 4B PHK
80/8924: 20EC9E JSR $9EEC
80/8927: 20E0F7 JSR $F7E0
80/892A: A901 LDA #$01
80/892C: 8560 STA $60
80/892E: E656 INC $56
80/8930: 60 RTS




Here is the "practice mode" (or title screen) track loading routine:
80/8ACD:    20D589      JSR $89D5
80/8AD0: 20E397 JSR $97E3
80/8AD3: 208AAB JSR $AB8A
80/8AD6: A901 LDA #$01
80/8AD8: 8598 STA $98
80/8ADA: 8581 STA $81
80/8ADC: 855C STA $5C
80/8ADE: 207BA2 JSR $A27B
80/8AE1: 20E6A2 JSR $A2E6
80/8AE4: 4B PHK
80/8AE5: 20E89E JSR $9EE8
80/8AE8: 20E6A2 JSR $A2E6
80/8AEB: 4B PHK
80/8AEC: 20E89E JSR $9EE8
80/8AEF: A92F LDA #$2F
80/8AF1: 8DA00E STA $0EA0
80/8AF4: 8DB00E STA $0EB0
80/8AF7: A9E0 LDA #$E0
80/8AF9: 8D270E STA $0E27
80/8AFC: 8D280E STA $0E28
80/8AFF: 8D290E STA $0E29
80/8B02: 8D2A0E STA $0E2A
80/8B05: 8D2B0E STA $0E2B
80/8B08: 8D2C0E STA $0E2C
80/8B0B: A901 LDA #$01
80/8B0D: 8561 STA $61
80/8B0F: 8560 STA $60
80/8B11: E656 INC $56
80/8B13: 60 RTS




Hopefully this will quicken the search for others reading the code.

I would love to see a fully functional track editor, so if you tell me what is most needed, I can try to focus my efforts on that. In the mean time, I'll continue reading through the code.
VL-Tone
Posts: 46/200
Originally posted by Heian-794
VL-Tone, great work!

While drawing arbitrary tracks may look imposing, we should be able to take frequently-used "sets" of 3x3, 4x4, etc. tiles to create curves and diagonals.

A while ago, before you figured out the row analysis this completely, I was looking at VSNES states and comparing their maps (can't think of a better word) to the array of tiles in the ROM. Here are a bunch of often-seen sets of tiles:

...

And now for my questions: I can't see the relationship between the compressed 2-byte value and the numbers that it encodes. 0F19 isn't the sum of 9A+9A+9B+9B, and neither is C676 the sum of all that stuff that makes it up... right?


C676 and 0F19 are not compressed data, they are address pointers.

The base address for the master row data is h10C13 in a ZST file. I had this mixed up in the other post. Note that the actual row data is starting at around 14C13 and is non continuous.

Just add a row's 16-bit address pointer to h10C13 to get the actual address in the ZST file.

h10C13+h76C6=h182D9

h182D9 is where you can find the start of the pictured row in a ZST file from Sand Ocean. Load 32 bytes at this address to get data for the full row.

5408 5600 5408 5600 5408 5600 5408 190F 5408 5600 5408 5600 5408 5600 5408 5600

h182E7 which is the address in the ZST where you can find 190F (the starting line 2x2 tiles pointer)

The green values on my picture had the bytes already reversed.

The starting line 2x2 tile offset is 0F19 and the 2x2 tile data begins at h64580 in the ROM so:

h64580+h0F19=h65499

In the ROM you will find 9A 9A 9B 9B at h65499 which are the four tiles used in the 2x2 tiles graphic for the starting line.

I hope it makes more sense to you now

I will address the part about an arbitrary track editor in my next post...
Heian-794
Posts: 700/896
VL-Tone, great work!

While drawing arbitrary tracks may look imposing, we should be able to take frequently-used "sets" of 3x3, 4x4, etc. tiles to create curves and diagonals.

A while ago, before you figured out the row analysis this completely, I was looking at VSNES states and comparing their maps (can't think of a better word) to the array of tiles in the ROM. Here are a bunch of often-seen sets of tiles:



Regular straight side barriers (formed by circles):

0 top left part of side barrier, driveable track on outside
1 top right part, driveable track on outside
2 bot. left part, driveable track on outside
3 bot. right part, driveable track on outside
8 top middle of barrier
9 bottom middle of barrier

52 top left part, black wall on outside
53 top right part, black wall on outside
54 bot. left part, black wall on outside
55 bot. right part, black wall on outside

Angled side barriers (lots more to get here):

108, 60, 30 straight-to-upper-right angled sequence top part; black outside
9, 135 bottom part of that

45-degree diagonal conbinations:

000 001 ... ... ...
054 051 147 ... ...
... 125 104 150 ... <- track on SE side; wall on NE side
... 127 128 048 001
... ... ... 054 051

052 053 ... ... ...
002 103 123 124 ...
... 149 104 126 ... <- track on NE side; wall on SE side
... ... 152 100 ...

014 015 140 141
068 069 070 071 <- NW-SE curve 30-degrees; track above
114 115 118 119

066 067 116 117
016 017 018 019 <- Same, but with track below
138 139 142 143

Other track elements (these are from Mute City):

105 pure black space; seen outside the barriers
154 ordinary gray track

167 rough
169 bottom left rough
170 bottom right rough
171 top left rough
172 right rough

154 174 154
172 206 173 <- remnants of a mine; 154 is regular track
154 175 154

185 pit area

194 lighter track

200 201
202 203 <-landmine


City/landscape outside the track (love this stuff!):

216-219 four corners of a circular rotating thingy
222 regular road far below the F-Zero course, horizontal
223 same road, vertical
232-233 other smaller roads (horiz, vert)
234-235 again w/other border
236-237 glowing line (MC; palette is metal gray in Port Town)

241 badge-like thing
242 glowing dot; green in MC2, magenta in MC3
244-247, 251-2 miscellaneous junk

These later ones are different in Port Town:

235 black space
238-246 purple elements
247-252 green forest elements


Forgive these all being in decimal; that's how VSNES displayed them. But if you convert them to hex, you should see that they match VL-Tone's table above.

Looking closely, you'll notice that the same tiles are used in the same spots all the time. Have a look at the first 0x99 tiles in the chart, which are all barrier parts. There are two of many of the parts, since sometimes you want track on one side, and other times you want its 'twin' which has air on that side and track on the other. For example, 104 (0x68) is the center of a barrier circle, and thus it has to have
147, 150, 128, and 125 to the N, E, S, and W of it, respectively, in order to make a barrier part with track to the NE and wall to the SE side.

I did most of my futzing around using Mute City, and you can see that rows D, E, and F contain the "under-track background" tiles, which vary depending on what track you're on. The other stuff seems to be constant for all tracks.

The palettes are controlled elsewhere, so we could always edit those separately.

And now for my questions: I can't see the relationship between the compressed 2-byte value and the numbers that it encodes. 0F19 isn't the sum of 9A+9A+9B+9B, and neither is C676 the sum of all that stuff that makes it up... right?
VL-Tone
Posts: 45/200
Originally posted by Sonicandtails
All going right over my head...Its so confusing! I know like 2% of ASM and like 20% of Hex and that all makes really no sense...Except for the track layout on the big number thing...Each number is a tile, set up in a order to display the track...right? Hmm...If I took the data you guys gathered on a level, and switched it around, would it work? Im trying really hard to process all this stuff so help me out.


Actually, I was more or less replying to Heian-794 which already knows things about the format, so it could be confusing for someone who didn't read the whole other thread. Still I guess it was still confusing to anyone

Let me try to make a simple explanation.

The basic graphic tiles are 8x8 pixels. Track panels are 256x256 pixels which means 32x32 basic tiles.

What defines what goes inside the panels are 16 pointers that are each 2 bytes long (16-bits).

Each pointer represents a row which is composed of sixteen 2x2 basic tiles graphics.

The number indicate what part of the row data will be used to display this particular row.



The whole row data itself is composed also of 2 bytes numbers but this time pointing to tile data.

The whole row data is uncompressed and starts at $10C13 in a ZST state for a particular track.

Each 2 bytes value in the row data is a pointer that represents a 2x2 basic tiles graphic.


The 2x2 tiles graphics data are also stored elsewhere, starting at $64580 in ROM.

Tile data is using one byte for each 8x8 pixels tile. So for each basic 2x2 tiles graphic 4 bytes are used.

Here is the 256 tiles set used by the tile data for Mute City (it's not the tile data itself)



If anyone already has the full set of these graphics for all tracks with all palette variations I would really need that. As you can see that palettes are off in some of my maps as I only have some of the graphic sets.

Anyway I guess the reason why it can get confusing is that the same thing is happening at several levels. The same "compression" method is used at the row and tile level, and actually it works much the same across the whole hierarchy of track parts:

Track/Panels/Rows/2x2Tiles/SingleTiles

If there is any part you don't understand, don't hesitate to ask...

Don't get too over hyped about editing the tracks. Even with this data, editing will be hard, unless someone designs a special tool to draw arbitrary tracks that would be then re-compressed as new panel, rows and tile data. That's how I think Nintendo proceeded, there is no way they worked by hand at the row and tile level unless they are really crazy Silence with its 90
Violent J
Posts: 403/749
All going right over my head...Its so confusing! I know like 2% of ASM and like 20% of Hex and that all makes really no sense...Except for the track layout on the big number thing...Each number is a tile, set up in a order to display the track...right? Hmm...If I took the data you guys gathered on a level, and switched it around, would it work? Im trying really hard to process all this stuff so help me out.
Yoronosuku
Posts: 126/502
Kyaah...I love F-Zero. That is so cool VL-Tone That would be incredible if we would be able to edit this.
VL-Tone
Posts: 44/200
Originally posted by Heian-794

Sand Ocean, for example, uses "00 70" as its default, blank tile. Does that mean that for the 16 bits, starting at the h70th on that master row data, we should see all 'empty' background?



0070 represents a complete row, not a blank tile.

The starting line panel for Sand Ocean starts at 1E9C0 and is 16x2 bytes long (32 bytes).
In that panel each 0070 is representing a row of water/sand.

4276 CE8E 8276 C676 C676 C676 C676 C676 C676 C676 F6CF 1875 6276 0070 0070 0070



This image is from my very early panel editor, you can click on rows and "slide" them left and right using the mouse. "Sliding" rows is simply a matter of adding or substracting even numbers from each of the row's values in the panel data. Adding will move the row to the left.

0070 is the position of the first data in the master row data set for Sand Ocean and Silence. A smaller value cannot be used. As you can see since subtracting slides the row to the right, the row shown for this panel would end up having the garbled tiles you see on the left (In the game they are even more garbled).

Now the next screenshot is to show what would happen if all rows would be selected at once in my editor, so you can see the context they're in.



Anyway I hope it makes sense to you

Ok now I found the missing addresses... The master row data is in ZST states from each track at: h24C47 and the length is at most 33510 (decimal) bytes. Some tracks share the same master row data.
As for the tile data used by the master row data:

Look at page 3 of the old F-Zero thread http://board.acmlm.org/thread.php?id=821&page=3

This 2x2 tiles definition starts at $64580 (in ROM). The 4 tiles have to be drawn in this order:
top-left, down-left, top-right, down-right.


At the time I didn't know what it was, and thought it was the row data, but it's the "reccuring" tile data used by the row data.

Heian-794
Posts: 693/896
Great info -- I need to take a few minutes to read and digest this; it's fantastic.

Sand Ocean, for example, uses "00 70" as its default, blank tile. Does that mean that for the 16 bits, starting at the h70th on that master row data, we should see all 'empty' background?

I'm going to put a little work into the graphics-only F-Zero hack that I was making a while back; Big Blue becomes a tropical island, Port Town is now a daytime course, and Silence is grassy fields with Stonehenge in the background. Might be a fun prelude to a real hack.
VL-Tone
Posts: 42/200
Originally posted by Heian-794
Sorry about that, Keitaro; I was thinking of his codes for switching which music plays on which course. Brand-new music in F-Zero would be great[!

Anyway, VL-Tone, do you think you could add the panel numbers to the parts of your graphics so that people know which byte values go with which course parts? For example, Death Wind looks like this:

I can probably pull the rest of them out of the ROM and post them when I have some more time.

Real F-Zero course hacking (not Climax's weak imitation) -- we've got to get this going!


What could be better than to put numbers on the map would be to generate all the panels in order on the same image, or in as individual image files. Then someone could use them to make a basic track editor that works at the panel level.

I actually cracked the format some months ago when I didn't have the net. I forgot exactly how it was done and I cannot find what I documented, so I'll have to dig up in my source code to explain it better. In the mean time, here is what I recall from memory:

There are 2 bytes for each 32x16 row, not one as you mentioned. This 16-bit pointer refers to a position in the master row data for this particular track. The master row data is itself composed of pointers (16-bits too I think) referring to 2x2 tiles (total of 32x32 pixels) in another data set.

It looks as if the whole track was designed with some custom tools, then "compressed" using this structure using a variation on RLE compression.

I only found the master row data in WRAM (in zst savestates), but the other data like the 2x2 tiles list are in the ROM, uncompressed.

If you still don't understand what I'm talking about when I mention "master row data" well here is some good old ascii art:

###########O.........O########O..............O#########O...................O#####



The pound signs are for "any out of track graphics" and dots are for the inside of the track graphics.The "O"s are... well you know, those round green or other color round things delimiting the track.

Imagine that the same string of characters would continue up to a length of 65,536 tiles/characters. Lets say the first 16-bits value (out of 16) for a panel is 000E. The corresponding row in the master row data will be found there in bold:
02468ACE...
###########O.........O########O..............O#########O...................O#####


Note that since the 16-bits value is referring to the actual position in the data that is also 16-bits, values are always even and in my ascii art, each character is represented as 16-bits in the 2x2 tiles data.

I'll try to dig the actual addresses of the data, and generate panel graphics in order.

And one last thing, I also cracked the car AI data...in part

There are pairs of lists of angles and speeds values (or maybe distance). I had no problems dealing with the angles, but the speed value is hard to predict, I couln't find a way to interpret the data so it could fit the tracks at every points (I'm guessing that I need to take acceleration into account).There are 4 sets of these angle/speed lists for each track, one for each car. I'm pretty sure now that the other "car drones" are surprisingly the only enemy cars that have real A.I. and really "drive" around the track.

Ok that's all folks for now... more soon.
Heian-794
Posts: 690/896
Sorry about that, Keitaro; I was thinking of his codes for switching which music plays on which course. Brand-new music in F-Zero would be great[!

Anyway, VL-Tone, do you think you could add the panel numbers to the parts of your graphics so that people know which byte values go with which course parts? For example, Death Wind looks like this:


00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 02 05 06 05 05 05 05 05 05 05 05 07 05 05 05 05 05 05 08 05 09 05 08 0a 0b 00 00 00 00 00 00
03 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 0d 00 00 00 00 00 00
0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00
0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00
11 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1b 1c 00 00 00 00 00 00
13 14 15 15 15 16 17 18 18 18 18 19 18 18 18 18 18 18 18 19 18 18 1a 18 1d 1e 00 00 00 00 00 00
00 00 00 00 00 00 1f 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 27 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 21 22 23 23 24 25 00 00 00 00 00 26 23 23 23 24 28 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 27 00 00 2a 2b 24 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 29 23 23 2c 2d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I can probably pull the rest of them out of the ROM and post them when I have some more time.

Real F-Zero course hacking (not Climax's weak imitation) -- we've got to get this going!
Keitaro
Posts: 1224/1342
I think it was my music stuff you mean, I remember posting a small document on how to hack the game's music (it was piss easy, SMAS format, I completly re-wrote the soundtrack at one point ). But I love F-Zero, I love the games and I love the music. I hope something cool could come out of this, and if I could assist at some point in the future, just look me up (I say the future because right now I'm a bit behind on some things )
Heian-794
Posts: 687/896
Looking forward to it, VL-Tone!

BTW, here's an old thread from almost a year ago where many discoveries were made in F-Zero. I'm looking at VL-Tone's research on checkpoints and Nestea's music stuff; we really need to get a hack/editor out of this!

Somebody bump it!

http://board.acmlm.org/thread.php?id=821&page=0
VL-Tone
Posts: 41/200
Oops! I just fixed that mix up...

I'm in a hurry, I have to go to work... I'll give you more info about it tonight or tomorrow.

And yes these are decoded from the ROM data...
BMF98567
Posts: 890/1261
Pretty cool, but I think you may have gotten Big Blue and Death Wind mixed up. Big Blue has the big, icy curve on the left.
iamhiro1112
Posts: 452/487
Sweet, I woudl love either a rom hack or a track editor for this game. The 1st gba F-zero tried to be that but it sucked big time.
JLukas
Posts: 25/51
Nice job, F-Zero is one of my favorites, great work with the maps!
Heian-794
Posts: 686/896
VL-Tone!!

That is fantastic!

How did you get these?

(For those unacquainted with F-Zero...: Long ago when we were working on hacking the game, people discovered how the game has 255 different 8x8 pixel tiles. Somehow the game assigns a single byte to a whole 32x2 row of these, then makes big 32x32-tile "panels" out of rows, numbers them (for example, in Mute City 0A is the starting line, 68 is horizontal track with a jump panel, 17 is blank air with city streets underneath, etc.) and then arranges the panels. But exactly how the game put those rows together, nobody could say.)

Tell me you've cracked this, VL-Tone, and that real F-Zero hacking can get underway!

There's an old thread about this; someone should dig it up. I probably have the last post, and thus can't bump it. But it's chock-full of information.
This is a long thread. Click here to view it.
Acmlm's Board - I2 Archive - Rom Hacking - Complete F-Zero tracks images (at last!)


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.006 seconds.