---

Here is some information I found about F-Zero's rival cars A.I.

At 7E0BD3 in wram is the on-track angle of the rival car in practice mode.
It's in 2 degree steps.

If you set this value via a cheat to 00 for example, you'll see that from the start,
the rival car faces left, and when the race start you see it go left and start to bounce
off the green barrier. So other cars do bounce on the barrier in that context,
but alas dont explode.

If you disable the cheat when the car is far away from where it should be,
you'll see that the car turns around and starts to drive toward an imaginary point
farther on the track, and this time it will pass through barriers if it has to.

I don't understand exactly what changes the behavior from bouncing to drive-thru-walls.
But the point it drives to is obviously it's next check point on the track so this pretty
much confirm that F-Zero uses a point-to-point A.I. for cars.

The drive-thru-walls game-genie code (for your car) is very usefull to follow the other car.

Angle values like FF will stop the car, and depending on where it is relative to you it will
either continously rotate on itself or stop rotating. A real speed value is probably near
7E0BD3, I'm looking foward to find it.

Note that the angle value is not exactly absolute, the game will rotate the car until it
reaches the angle stored in 7E0BD3 so turning not instantaneous. Suden 180 degrees
changes may not trigger the rotation.

So here is the way it probably works:
The game calculates the angle between the car and it's next check point.
Then, it stores this angle in 7E0BD3, and the game starts to make the car turn until
it reaches the right angle.

When the car is close enough in distance to the check point, the game steps in so
it aims for the next check point. The checkpoint data probably also includes speed
info for each point so the cars can slow down in some tight turns.

Around 7E0030 in wram there are various position values for the enemy car.
Some 16-bit X and Y pointers for its position on the track and another X and Ys
that seem to be the relative pos between the rival car and your car position.
Also there is 7E0BD3 mirrored near that.
I wasn't able to patch those with cheats, they are probably mirrors too.

---

---

Look what I've found... at 7E0D02 in wram is the checkpoint counter for the rival car!

It starts at 00 and increment as the car passes through the check points until 3A
(in Mute City 1) when the car reaches the starting line, then it goes back to 00.
Note that again this apply to the practice mode.

It means there are around 59 ($3A+1) checkpoints in MuteCity 1. Using a cheat you
can patch it to any value in this range and see the car turn around and head towards
this checkpoint. Put 00 in 7E0D02 while the rival car is in the middle of the course,
and you'll see it head for the starting line.

As I predicted, the car won't turn around if it has to do a 180 degree turn, so when it
reaches the check point it start to drive in a straight line, wrapping around the track.
If you then remove the cheat, you'll see that the value was incremented elsewhere
and that it has reached a higher number, and the car will head up to the point it was
supposed to be.

This mechanism is probably used in the grand-prix mode for the cars behind you to catch up.
By incrementing the counter faster than the cars would, it forces them to take short-cuts,
and they catch up with you, maybe it actually fetches them the last checkpoint you activated.


So we're closer than ever to find the actual checkpoint data which must have 59 entries
for Mute City 1.

EDIT: I didn't look for the car abilities values yet, to find them you could make a savestate
for each rival car at the starting line of Mute City 1 in practice mode.
Then you use a cheat finder to see what values are different, if you eliminate things like timers that could be different, you should end up finding data that is specific to each car. Fiddle with
the bytes in ram to see what they do, and then you can try to look for that data in the ROM.

---

---

VL-Tone, is the car obeying the rules (i. e. not driving over empty space) when you change its next checkpoint?

---

---

The car doesn't obey these rules and will drive in a straight line to it's destination point,
even over empty spaces outside the track. But like I said I'm trying to figure out the details,
if you force the car to drive at a specific angle that is not towards the next checkpoint,
it will bounce of barriers like your car.


I'm using different techniques to find these values, to find the checkpoint counter, I ran the cheat
search at various points in the race, looking for values that were higher than the last sample.
Eventually I got down to a dozens of bytes, and by putting them as watch points so they are
showing on the snes screen, I quickly found that one value cycled from 0 to 3A and back to 0
when the car made a complete lap. Since the value was incremented at various time intervals,
it was clear that this counter had to do with checkpoints. Then when I patched the value it
comfirmed that this was it.

I didn't try to find the actual point list since ( I had to go to work until 9:30pm), but I'll start again
after this post. I'm thinking of doing a program that draws paths from a list of 16-bit X and 16-bit Y
values. The program will take the values from the f-zero rom at successive adresses while hoping
to find a track path pattern.

EDIT:
Dang I found the cars A.I. path data in WRAM!!!!!

At $7E11FE in wram the X data is stored in 16-bit chunks.
And at $7E1467 in wram the Y data is stored again in 16-bits chunks.

Look at these pictures (in .png format) of the Mute City I car path.
They were done using a custom tool I made for the occasion.
The map on the background was made with Tyler's set of panels, but half are missing.

http://homepage.mac.com/qubedstudios/MuteCityPath_HighByte.png
http://homepage.mac.com/qubedstudios/MuteCityPath_16bits.png
http://homepage.mac.com/qubedstudios/MuteCityPath_Fixed.png

-->The first one is drawn only using the high bytes of the data.
-->The second one is using the 16-bit value as normal, note the weird zig-zags this introduce.
-->And the last one is using inverted low bytes (FF-xx) and it seems to correct most anomalies.

Now the data can be found and extracted from savestates, but I cannot find it in ROM.
From what I concluded, the data is built when loading the track by adding a series of values
to the starting positions found at around $16200 in ROM. That explains why the path
of other cars is relative to the starting pos value. You can see that the first values at
$7E11FE and $7E1467 are the same as the starting pos in ROM. Just before each starting
pos values after $16200 in ROM are the checkpoint counts, which is 3A for Mute City I.

---

---

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

---

Posted by HyperHacker

---

Hm, but in the game, King Bob-omb doesn't appear on act 6.

---

Posted by residentevil64

---

How do you make marios head peach???


http://acmlm.no-ip.org/archive3/thread.php?id=7112&page=15


like on here

---

Posted by HyperHacker

---

Leet hax.

Hm, looks like act 6 uses whatever act you haven't beaten yet. If you get #6 first, King Bob-omb is still there, and once you beat him, go to #6 again and Koopa The Quick will be there instead. I didn't get a chance to see what happens if you e.g. get #6, then one besides #1, and play #6 again, because it doesn't seem possible in level 1. You need #1 to get #2, you need #2 to open the cannons, and you need the cannons to get #3 (on the island), #4 (red coin on the island) and #5 (shoot from the island). :-/

---

Posted by HyperHacker

---

God damn you Ctrl+W. God damn you.

K, so... in MK64 I discovered the commands didn't behave as expected. Changing a one-byte Disable Culling command to a one-byte NOP broke other things. Turns out the level script actually generates GBI commands which are referenced by pointers elsewhere. By changing a Disable Culling command (which generates one GBI command) to a NOP (which generates none) I had changed the location of these GBI commands which broke the pointers. Maybe your problem is similar.

---

---

I checked a FAQ and it looks like you can get star 6 first in most levels. Those you can't, it's because you need to open the cannons first on some other act.
That script dump is interesting. By debug menu I take it you mean level select?

---

---

So level number is 32-bit? The only level modifier code I saw at BSFree is 16-bit (at 8032DDF8). 0064, 0065 and FFF7 freeze the game. Do you know where it's pulling this value from?
Also, yes, try selecting invalid levels on the level select screen, you go back to the title.

Interesting too that the menu is a level. Maybe we can make our own menus then.

---

---

Now what do you think is up with the lack of 00 through 03 in this table?

---

---

BTW, you might find this code by Viper187 interesting:
8933B4A0 ????
8933B4A2 ????
8833B4A4 00??
Press the GS button before entering a painting and it will warp you to the specified location.
0000 0000 0000: Wherever the painting normally goes
0108 0802 000A: Shifting Sand Land pyramid
010C 2402 000A: Tall Tall Mountain slide

---

---

Parasyte also found this at 8033B408:
At this address, you'll find a list of maybe 12 - 16 pointers. Just add 0x80000000 to each pointer, and of course you'll have a nice, valid mapped RAM address.

The first pointer, pointer-0, points to data for on-screen textures, water, and sky.
pointer-1 points to data for trees, doors, etc etc.
pointer-2 points to Mario's texture and model data.
pointer-3 points to yoshi.
pointer-4, I can't tell what it points to.
pointer-5 points to world model data.
pointer-6 points to the item boxes.
pointer-7 points to world texture data
pointer-8 points to the sky texture set

---

Posted by CrashDance22

---

Well this thread hasn't had a new post in a few days (surprisingly), but VL-Tone, do you think it's possible to map those textures to the Blargg some time in the future? It shouldn't be more than wrapping the "jellybean" texture around the model, then sticking the eye textures where they need to go. And do you know what might be causing the level's geometry model to not load? Like I said, I think there's some sort of "loading restriction" for certain 0x24 commands.

---

Posted by CrashDance22

---

Oh, I see. But I don't understand what you mean by editing a 0x22 object to point to the model ID. In fact, I don't even understand how 0x22 objects behave, load, etc., which got me stumped. And speaking of level objects, the case is quite different with actual level pieces, like in Tall Tall Mauntain. They're 0x24 objects to begin with, but then again probably just another 3D object... my point is that I have no problem applying level parts to those objects.

And about modifying collision data, I think that would be great for creating invisible mazes to crawl through and things like that, but would that allow us to apply a certain section of collision data from a level to a single model? For example, outside the castle you can move the castle spire, and it's collision data would still be in the same place, upon the castle. I'm wondering if there's a way to make it stick to the object realistically, but it's probably not possible since the collision data is in different groups?

---