Acmlm's Board - I2 Archive

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 - F-zero Maximum Velocity & GP legend

User name:

Password:

Reply:

<blockquote>Originally posted by BGNG<hr>Okay... I've been digging around in the second half of the Non-Japanese ROM for about two hours, and I've found some nice little pieces of data. Here's what I've found in the memory map:

<TT>3c0000 3f0000 - Backgrounds & Horizons (Image Data)
3a0000 3c0000 - Text & Some Background
370000 380000 - Some Course Maps (Sprites)
1d0000 1e0000 - Some Tile Sets
1c0000 1d0000 - Major Scrambled Pawn 1</tt>

<HR Style="border: 1px solid;">
I've also found the course information definitions, which stores the course name, palette, music, and some other unknown (and unapparent when changed) data. Here's my document of that:

<TT>2B4EF0 - Course Info Definitions (76 bytes each)

00 1F - Unknown
20 3F - Name (Uppercase ASCII only)
40 43 - Music
44 47 - Unknown
48 4B - Palette

Course Order:
Knight 4 & Bishop 2
Pawn 3
Queen 4
Bishop 3
Pawn 5
Knight 2
Pawn 2
Knight 1
Championship
Pawn 1 & Bishop 1
Queen 5
Queen 1
Queen 2
Queen 3
Bishop 4
Bishop 5
Knight 3
Pawn 4
Knight 5
Unknown (Synobazz 3?)
Single-Pak Game

Music Constants:
00 00 00 00 - (No Music)
04 AC 12 08 - Bianca City
10 B4 12 08 - Crater Land
14 C4 12 08 - Beacon Port
20 DA 12 08 - Stark Farm
60 CF 12 08 - Fire Field
70 E5 12 08 - Synobazz
80 06 13 08 - Ancient Mesa
B8 FA 12 08 - Cloud Carpet
CC 90 12 08 - Empyrean Colony
EC A1 12 08 - Tenth Zone East

Palette Constants:
0C 95 36 08 - Ancient Mesa
0C 97 36 08 - Beacon Port
0C 99 36 08 - Stark Farm
0C 9B 36 08 - Tenth Zone East
0C 9D 36 08 - Synobazz
0C 9F 36 08 - Bianca City
0C A1 36 08 - Fire Field
0C A5 36 08 - Crater Land
0C A9 36 08 - Empyrean Colony
0C AB 36 08 - Cloud Carpet
0C B5 36 08 - Silence</tt>

Putting that into practice, we get stuff like this:

As you can see, there are two chunks of data that are shared by two courses. This will prove to be an inconvinience when naming new courses, but those two pairs are the only incedences of that.

<HR Style="border: 1px solid;">
And as I mentioned in the map up top, I found a "Major Scrambled Pawn 1"... Racing on this course, all course features behave as they appear to, and there are no restrictions as to the normal flow of the course.

This is in fact the level data for Pawn 1.

<HR Style="border: 1px solid;">
That's all for now. I'll update again later in the day.

<HR Style="border: 1px solid;"><HR Style="border: 1px solid;">
EDIT:
I've isolated the starting bytes of Pawn 1 and Pawn 2 in the ROM (Non-Japan version), and I've found that they don't end on 16-byte boundaries. Pawn 1 is at <TT>1CE410</tt> and Pawn 2 is at <TT>1CCAD2</tt>. Since Pawn 2 starts at xxxxx2, the courses must not all exist on a 16-byte boundary. This could be evidence of variable-length data segments for course definitions.

I have found, however, in my first attempts to crack the data, that it's either generated off of a seed or the data is compressed; likely the latter. If it's compressed, then there's a real possibility that we may have a very limited number of bytes to work with; which may hinder the creation of new courses.

<HR Style="border: 1px solid;">
But whatever the incedences, I moved the first several bytes from <TT>1CCAD2</tt> to <TT>1CE410</tt> and successfully imposed the Pawn 2 track data on Pawn 1:

<HR Style="border: 1px solid;"><HR Style="border: 1px solid;">
EDIT 2:
Looks like my suspicions were correct, but it's not all that bad. I've isolated the locations of all courses in the game ('cept for Championship, Single-Pak Game and possiby that mysterious "Synobazz 3") and calculated the differences in offsets to get the file sizes. Here's what I've found:
<Pre>Offset Course Size ------------------------- 1C872A Knight 1 1,832 1C8E52 Knight 2 2,910 1C99B0 Queen 4 2,596 1CA3D4 Pawn 5 2,026 1CABBE Bishop 4 2,168 1CB436 Bishop 2 2,168 1CBCBA Bishop 1 1,848 1CC3F2 Queen 1 1,760 1CCAD2 Pawn 2 1,988 1CD296 Knight 3 2,428 1CDC12 Bishop 3 2,046 1CE410 Pawn 1 2,014 1CEBEE Pawn 3 2,616 1CF626 Queen 3 1,832 1CFD4E Pawn 4 2,240 1D060E Knight 4 2,802 1D1100 Queen 2 2,298 1D19FA Queen 5 2,378 1D2344 Knight 5 2,460 1D2CE0 Bishop 5 Unknown</pre>These might not be 100% accurate. I have not verified them for complete accuracy, but they'd only be 1 or 2 bytes off if any.

Take note that Pawn 2 is smaller than Pawn 1. Because of that, it was possible for all of Pawn 2's data to be transposed to Pawn 1 without error.

I'll still have to look up where the Championship and Single-Pak Game courses are stored. They're not in the same spot as the other 20. And there's also that nebulous "Synobazz 3" floating about. It just might be a hidden course.<hr></blockquote>

User	Post
Heian-794 Posts: 889/896	There's something I could do while I'm away and don't have access to my computer (off to Europe for ten days on Thursday): I'll take the printouts with me and start listing blocks of metapanels. Redefining tiles might still be useful for people who want to go beyond basic level editing and release finished, edited-in-all-sorts-of-ways hacks. For example, many people here have used Lunar Magic to edit Super Mario World levels, and then followed this up by editing graphics, sounds, other data, and even assembly code. So our level editor should ideally work with the original game, but should still allow for people who want to edit the game further. Maybe recommend that people make new tiles in the free space.
BGNG Posts: 252/276	I wouldn't recommend redefining any of the panels on a tile-based level. If all the panels are left as they are, then that will allow for courses to easilly be implemented from other sources. If the panels are redesigned, then some courses will be biffed and fail to display correctly. But as far as "metapanels" are concerned, those can just be defined in little "metapanel library files" and imported into the editor at run-time. That way, any number of "metapanels" can be supported and the selection can be upgraded whenever new data is available.
firemaker Posts: 225/247	Yes it would. A level editor on 3 levels. A metapanel stage, normal panels and tiles. It would work very well indeed. Those who wanted just to create a simple course could just use the metapanels while tose who wanted to creeate a stage panel by panel and use their own panels would use just a panel stage.
Heian-794 Posts: 886/896	Firemaker, I misunderstood you. I thought you meant that you wanted the game (not the editor) to have bigger panels, and if we did that, our editor would be no better than the mediocrity that is Climax. So we could define quite a number of metapanels of various sizes and then get the editor to display a mixture of those plus whatever regular 8x8 panels we want to add in. That would be ideal.
firemaker Posts: 223/247	Originally posted by HyperHacker You don't need to reprogram the game to have these 'metapanels'. You select from a set of 32x32 panels, each made up of several 8x8 panels. You place it on the track, and the editor automatically places the appropriate 8x8 panels. Suppose you had a big panel made of panels 00 - 0F; when you placed it on the course the editor would just place panels 00, 01, 02 and 03, then below that panels 04, 05 and so forth. At least somebody got what I meant. tthat make good use for those who couldn't be bothered to look through 3000 tile pieces.
Heian-794 Posts: 883/896	HyperHacker, that's a good plan. What if the "metapanels" aren't square? Any idea how to implement it in Visual Basic? For example, there are many places where there are groups of "bound" panels that are designed to be used together, yet parts of them can also be used independently. In this shot, using only panels up to 0x40, the red rectangles surround the "metapanels" used in the actual game, but the green rectangles surround parts of those which, thanks to the barriers being in just the right places, could easily be used by themselves. If you look carefully, you'll see that the game designers implemented the panels roughly in the order that they were needed -- the basic "blank course" panel became necessary at 0x000F, and they then used two of them, before going on to 0x0010. If we could pre-define those big blocks, letting the user fill in anything desired in the empty areas (0x000F for instance), course editing would be a lot easier!
HyperLamer Posts: 6505/8210	You don't need to reprogram the game to have these 'metapanels'. You select from a set of 32x32 panels, each made up of several 8x8 panels. You place it on the track, and the editor automatically places the appropriate 8x8 panels. Suppose you had a big panel made of panels 00 - 0F; when you placed it on the course the editor would just place panels 00, 01, 02 and 03, then below that panels 04, 05 and so forth.
Heian-794 Posts: 881/896	Firemaker, the panel size is fixed at 64 tiles, 8x8. Each panel is 1/64 of the course width. In Climax, a panel represents 1/16 of the course width, or 4x4 MV panels, or 1024 tiles. So we would have to somehow tell the game to only draw 16 panels, and, when making the panels from the tiles, to read the next 1024 bytes instead of 64, and to read them in lines of 32 instead of lines of 8. I'm not sure how possible this is, but even if it were possible, we would then have to design some really good "super-panels". And the problem of not having enough panels to make a good course (256 is too few) would be back in our faces again. Maybea collection of 767 16x16 panels (four times as large as real panels; 0xBFD / 4 = 0x2FF = 767) would be a good compromise, but the work involved wouldn't be worth it. The smaller 8x8 panels are fine; I just think that we might need to add more"properly-aligned" panels, i. e. ones that begin and end right on the edge of a barrier circle. Those are much more useful than the ones that end with barrier bits cut off at arbitrary points, because then you're constrained as to which panel you can put next to it. With a handy collection of these on screen in a kind of toolbox, we wouldn't have to go searching for a panel that fits. The game seems to allow for 0xFFFF different panels, even though there are only 0xBFD of them. The panels begin at 1D43FC, and since each panel is 64 tiles wide, we should be able to point to panel definitions that are (0xFFFF x 0x40) bytes away in the ROM, meaning that we could maybe put some custom panels in the free space at the end. A few dozen neatly-made curves, corners, and slants would be a huge help in making courses, and we don't want to have to overwrite "real" panels, since that would mess up existing courses and thus basically commit us to editing the entire 22-course lineup. Another option would be to take some of the redundant panels -- there are a lot -- and put our original panels there, "fixing" the game's courses so that they don't make use of the redundant panels. Then the free space would be available for new courses only. I'm going to try to get those text boxes in the editor so that it's a little more useful. Starting on Thursday I'm going to be away from my computer for a week (going to Europe) and it would be nice to have some tangible progress for everybody.
firemaker Posts: 221/247	Heian-794 In answer to your problem Why don't you do what Climax does. Have bigger panels made out of small panels, then afterwards you can edit those big panels. That would really help those who don't want to spend ages making each course.
Heian-794 Posts: 877/896	BGNG, OK, so I can basically just multiply those numbers by 4 to get the real numbers. Each panel is then 0x10 units on a side, and my map of 32 x 24 tiles is then 0x200 x 0x180 units. Being able to arrange paths to 4-pixel accuracy is great -- we can have the computer cars sneaking in the gaps between damaged track and barriers; going right between twist circles, etc., etc. Can I fill in the excess points by simply repeating the last point over and over? This test course only needs to have one path, since there are no splits, and no pit areas that aren't in the middle of the course. I'm starting to wonder if, if producing a full-22-course hack, it might not be better to draw the courses at the tile level and then make up our own panels based on those. While there may be over 3000 panels available, it can be difficult and frustrating to find ones that line up as you want them to.
BGNG Posts: 251/276	Looks like I did my math kinda backwards... The whole width of the track will be `3FF`... So 1024 / 64 panels wide is 16 units per panel. And 16 / 8 tiles wide is 2 units per tile, not one unit per two tiles. So 0,0 is the top-left corner, 1,1 is in the middle of the first tile (4 pixels in each direction) and 2,2 is at the bottom of the first tile. The numbers are stored as 16-bit, unsigned integers, so you'll have to stick a `00` to go with each of your values. After the path points are plotted, you'll have to connect them together with the path definition, which immediately follows the points. These are pairs of bytes determining the point to use for the next point of the current path (since there are two paths in every course; they'll often coincide). I'm not sure how to change the number of points to use in the path definition, though.
Heian-794 Posts: 875/896	BGNG, let me see if I understand you right. In the course above, the starting line would be at (12, 44) in decimal, or `(0C, 2C)` in hex? This means that each actual panel is 4 units, and each 8 panels, as seen in the editor, represent 0x20 units. Handy. My course above is thus 0x80 units wide and 0x60 units tall. So I could then put (staying in hex) another point at (0C, 16) for the first turn, then: `28, 16 36, 06 4A, 06 (just north of the rough) 4D, 08 54, 0C (avoiding the twist circle) 58, 18 60, 18 (navigating through the narrow part) 64, 14 68, 0C 78, 0C 78, 44 (OK not to have intermediate points on the backstretch?) 74, 44 (heading into the dash plate) 2D, 46 (hitting the last dash plate) 10, 48 (middle of the lower path) 0C, 44 (jumping off) 0C, 3C (landing point)` ...for a full circuit of the track! If this looks good, let me know so I can put it in the game along with this test track!
BGNG Posts: 250/276	If I remember correctly, the path coordinates clamp to `0` to `3FF`, which is 1024 coordinate units.That means that one unit accounts for two tiles, or 16 pixels on the map. 0,0 specifies the top-left corner; the pixel in that spot. And you can use a text box fairly easily. Just stick one on the Form (Text1) and say something like "`Variable = Val("&H" & Text1.Text)`" to convert the user-typed-in value from Text1 (as hexadecimal) into a number the program can use.
Heian-794 Posts: 874/896	Firemaker, I've extracted, and then taken screenshots of, every last one of the panels, and you can view them here: Panel screenshots, ZIPped I printed these pages out and used them to plan out the sample course, which I'm going to try to implement. This course is only 32x16 panels, instead of the "real" 64x64 size. Consequently I'm hoping to be able to put this in the game without having to compress it. Here are some screenshots of the course I designed, using only existing panels and no custom-designed ones. I can only describe the entry of these panels into the editor as "painstaking" since I'm entering them directly into the code and then running the program. (BGNG, I'd like to have little text boxes where the user can change panels on the fly instead of having to re-run the program; is this possible?) So. Screenshots here (your screen needs to be four thumbnails wide): (Forgive the image-intensiveness!) I now see that I botched the connection between two of the panels on the top row; got to fix that. Also, the starting line is on the left and is a bit hard to see. I only attempted one "exotic" thing and that was to put ramps on the side of the course and have the player jump off them to get to the finish line. Now I have to measure the X and Y coordinates of these panels so that the computer cars can drive also, and so that the starting line is where it belongs. BGNG, are those in "8x8 panel" units, or tiles?
BGNG Posts: 249/276	You already have the panels in the ROM at `1D43FC`. Using the tile and palette information, you'll be able to get pixel images of the panels fairly easily. But they won't do you much good unless you have a use for them. I recommend at LEAST making a compressor before trying to do anything with the panels.
firemaker Posts: 194/247	Just out of intrest could either off you send me all te usual panels. I'm planning on putting an editor together for myself done in C++. Haven't started the editor itself but have got all the plans ready. I would just like to have the panels though to save me writing an extractor program.
Heian-794 Posts: 867/896	Well, this is a busy board, so even going two days without a post will send ths thread downwards. As long as we're making regular progress, it should be fine -- though people will get upset if we bump a months-old thread. I've managed to design a 16x16-panel mini-course that lines up perfectly. Now I want to go back and look at your data on checkpoints so that it can be driven properly, and then try to compress it and insert it into the ROM. Since the course is so small, and has lots of `00` panels in it, optimum compression shouldn't be necessary and it should be easily slotted into one of the pther courses' places. There are about a dozen things that could go wrong, but I'm going to have a go at it and see what happens. If this works, the next step will be to add some kind of panel-grouping-in-progress save feature to the editor, so that people can take the stuff that they've been working on in the "sandbox" window above, and connect them to form full courses. Something that would automatically read the edited panels and convert them into points, replacing the existing points, would be nice too. (I. e., searching for non-00 panels, recording their X and Y positions, and making that the path) Any ideas on that? Edit -- You won't be seeing this particular combination of pieces in the game (and with good reason as it's not elegant and should be tweaked ^^, but with an editor all things are possible! More editing: My custom course is just about finished, design-wise; now I have to compress this and get it into the ROM. BGNG, do you have any more comments on the table of path points aside from what you mentioned towards the beginning of this thread? Are the X and Y in "tile" units or panel units? Pixels, even? If they're stored as 16-bit numbers, anything is possible. But I'd like to program a path for my course so that we can see other cars driving on it.
BGNG Posts: 248/276	Alright. You're the boss. (-: If all hacking goes for you, then all hacking this thread will be. It looks like this thread is preparing to go the way of the snowman, so we'll have to devise if we want to continue posting findings here or if we should arrange another form of communication for the project.
Heian-794 Posts: 861/896	Well, you're right that level editing is the main focus, but there are still lots of other aspects of FZMV hacking that are worthy of attention, especially if you're more capable in other areas and another person is working on the level editing. I'm happy to see contributions in any area of the game. But back to the level editing -- it looks like the game must keep a database somewhere which details which tiles are driveable, which are damaging, and which are "blocking" (sending you backwards), because their appearance is arbitrary (see the "new course surface" screenshots). That makes me want to mess around with the twist circles a little (in the E0-FF range of tiles). A course where hitting those works to your advantage might be fun.
BGNG Posts: 247/276	Hold your horses, Heian-794. Car stats and bomb appearence has nothing to do with level editing. It may not have been officially declared, but level editing is what this thread is dedicated to. Graphics hacking should only be performed when it's applicable to level editing. Things like venue floors modifications don't count. As you've undoubtedly noticed, the game responds to the panel layouts by the tiles that it describes. "Barrier" tiles act like bariers, pit area tiles like pit areas, etc. This way, any configuration of panels can be made and they will act accordingly without editing the programming whatsoever. The mines are just more tiles. Tiles that, when you drive on them, explode. They simply turn the entire panel into panel `02`. Easy pickin's.
This is a long thread. Click here to view it.

Acmlm's Board - I2 Archive - Rom Hacking - F-zero Maximum Velocity & GP legend

ABII

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

Page rendered in 0.014 seconds.