 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by VL-Tone |
| Pages: 1 2 3 4 5 6 7 8 9 10 |
| User | Post | ||
VL-Tone Red Cheep-cheep Level: 23  Posts: 1/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Hello there fellows, I know some of you but you may not know me, I'm not a newbie to ROM hacking, but I never registered on the new boards. Still I did a couple of post on the old old board, as I'm following this site since the SMB2 Discombulator days. I'm the author of Metroid Cubed, or as some call it "Metroid Skewed", a volumetric 3d conversion of Metroid 1. As I remember, it got a Lukewarm reception here  (I didn't post about it, I just followed a referer from my stats tracker and lurked) Anyway these are not exactly skills but I have good knowledge of the SMB 1,2 and 3 and Zelda 1 level format and very good knowledge of Metroid, including many things not documented by SnowBro (probably some of this is in it's commented source code though, but parts are unclear) . I have a Metroid editor that is almost finished for sometimes, you can try it online on my page using Shockwave , wich seems to be very popular here... not!  There are other things in the works that you can see on my page, but as far as ROM hacking is concerned, F-Zero and StarFox are the games I'm trying to hack these days. I found very interesting things in Starfox that reveal how the level are stored (though I dont know where in the ROM yet) I hope to tell you more about it soon. As for F-Zero, see my revealing post about it in the rom hacking board. Well that's pretty much it for now Metroid Cubed, Zelda Cubed, 100 Marios and other NES related Shockwave silliness are at: http://pages.infinit.net/voxel/home.htm VL-Tone ---Everything counts in large amounts--- |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 2/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Wow the holy grail! Let me have it I don't know if it has been mentionned elsewhere (well actually when I finished writing this post I found Heian-794 was on the right track) . Anyway since this thread was running with only basic discoveries (things I figured out long time ago), I'll share what I've found with you (after all it's the old acmlm board that got me interested in ROM hacking, in the SMB2 Discombulator days). Here is what I discovered: The format is actually very close to the Zelda 1 overworld data. Like mentioned before there is a 200 bytes meta map of 32x16 track parts or panels (let's use this term for clarity) making up the whole track. The panels are themselves made of 32x32 8x8 tiles. Now HERE IS HOW THE 32x32 TRACK PANELS ARE STORED IN F-ZERO: Columns... or actually rows Each row is 32x2 tiles and 16 of them are needed to fill the 32x32 panel. The row is referenced by a 16-bits pointer so each panel definition data is taking up 32 bytes. As an example: 9E 70 30 75 F2 91 F2 91 F2 91 F2 91 F2 91 F2 91 F2 91 F2 91 F2 91 F2 91 3E 7C 06 78 FC 9F 92 77 is the starting line panel in Mute City (at 7F5140 in RAM and 15E93 in a ZST). This data is somewhere in the ROM and is compressed... BUT... it is decompressed in RAM starting at 7F5000 and in a ZST savestate from 15C13 to 16B93. Finding the row pointers for a specific panel simply involve adding 32 bytes X the panel number to the base address. Just before that are 2 versions of the 200 bytes 32x16 track map. As you may know, if you try to edit these maps in the ROM, they end up being patched at a few places by the game depending on if you are on Mute City I or II for example. From what I saw it seems the two RAM versions are already patched versions of the I and II track. So the first row of the starting line for Mute City is at 7F5140 in RAM and at 15E93 in a ZST savestate. Note that this base address is the same for all tracks and the data content will change when you switch tracks in games and for the ZST state it depends on when you saved it. The 16-bits row pointers works this way: Let's take the first row from the starting line panel in Mute City. It's value is 709E (9E70 in the data), the 709 will point to one of the row, and the E will actualy shift the data in 2 (8x8 pixel) tiles increment so you can position barriers ect... at 16 different positions for each row. My explanation is probably confusing, but its really simple: If you skip 16 bytes increments you will skip full rows, if you skip less than 16 (let's say 8) you will end up in between 2 rows, which can be very usefull and is used all over the game and the row data is designed accordingly. A level editor would probably include a way to "scroll thru" the row data in one or 16 bytes steps while you edit. Some usefull features could include shifting all the rows from a panel at the same time (by dragging the mouse over them) so you can align the whole road with other surrounding panels. Now for the unconfirmed stuff: The data defining each row , is probably using single bytes macro tiles like zelda did to describe each 4x4 tiles forming the 16x16 pixels tiles referenced by the column definition data. This part is still experimentation for me, but I'm almost sure that the row definition data in F-Zero is starting at hex 38620 in the ROM, and that it's 16 bytes for each visible 32x2 tiles row, and uncompressed. Back to mostly confimed stuff: The list below is an overview of the range of row types used in Mute City. As I discovered, if you try values outside of this range in Mute City (for example 500x) you'll mostly end up with garbage rows, they are rows for other tracks with the wrong graphic set. Each track can only access a set of rows but some rows are shared by multiple graphic sets it seems, I didn't map those out yet, but it clearly looks like the whole row data ranges from 0000 to FFFF (64k), which means a whopping 4096 different 16 bytes rows are available in F-Zero, and actually with the 16 bytes shifting it's about 65 000 different combinations! -----Row pointer range for Mute City---- 404x 407x 40Bx 414x 417x 41Ax 41Bx 424x 429x 42Ax 434x 43Ax 444x 447x 449x 44Ax 44Bx 454x 706x 707x 708x 709x 70Ax 70Bx 70Cx 717x 718x 71Ax 727x 729x 72Ax 72Bx 737x 739x 747x 748x 757x 759x 767x 768x 769x 76Ax 777x 778x 779x 77Bx 787x 789x 78Cx 797x 798x 799x 79Bx 7A7x 7A9x 7AAx 7ABx 7ACx 7B7x 7B8x 7B9x 7BAx 7C7x 7C8x 7C9x 7CAx 7CBx 7D7x 7D8x 7D9x 7DAx 7DBx 7E4x 7E8x 7E9x 7EAx 7EBx 7F7x 7F8x 7F9x 807x 808x 809x 80Ax 80Bx 817x 818x 819x 81Cx 824x 827x 828x 829x 82Bx 837x 838x 839x 83Ax 844x 847x 848x 849x 84Ax 857x 858x 859x 85Ax 85Cx 867x 868x 86Bx 874x 877x 878x 879x 87Bx 888x 889x 88Ax 897x 898x 899x 8A7x 8A8x 8A9x 8B7x 8B8x 8B9x 8C8x 8CBx 8D7x 8D8x 8D9x 8DBx 8E7x 8E8x 8E9x 8EBx 8F7x 8F8x 8F9x 908x 909x 90Ax 917x 918x 919x 91Ax 91Bx 927x 928x 929x 92Bx 937x 938x 939x 93Ax 947x 948x 949x 958x 959x 95Ax 964x 967x 968x 969x 96Ax 96Bx 977x 978x 979x 97Ax 97Bx 988x 989x 98Ax 998x 999x 99Ax 9A7x 9A8x 9A9x 9AAx 9B7x 9B8x 9B9x 9C7x 9C8x 9C9x 9CAx 9D8x 9D9x 9DAx 9E4x 9E8x 9E9x 9EAx 9EBx 9ECx 9F7x 9F9x 9FAx A07x A08x A09x A0Ax A0Bx A19x A1Ax A1Bx A24x A27x A2Ax A37x A39x A3Ax A47x A49x A4Ax A54x A57x A58x A59x A5Ax A5Bx A5Cx A6Ax A6Bx A74x A77x A79x A7Ax A84x A87x A8Ax A97x A98x A99x A9Ax A9Bx AA7x AA8x AA9x AAAx AABx AB7x AB8x AB9x ABAx ABBx AC9x ACAx ADAx ADBx ADCx AE9x AEAx AEBx AECx AF4x AF7x AFAx AFBx AFCx B07x B0Ax B0Bx B19x B1Bx B1Cx B28x B2Ax B2Bx B2Cx B34x B37x B38x B39x B3Ax B3Bx B48x B4Ax B4Bx B57x B58x B5Ax B5Bx B68x B6Ax B6Bx B7Ax B7Bx B7Cx B8Bx B99x B9Bx B9Cx BAAx BABx BACx BB8x BBAx BBBx BBCx BC7x BCAx BCBx BCCx BDAx BDBx BDCx BE7x BEBx BF8x BFBx C08x C09x C0Ax C0Bx C0Cx C17x C18x C19x C1Bx C1Cx C27x C2Ax C2Bx C2Cx One last thing try these cheats: 7E0BB0:1A 7E0D51:80 7E0BB1:00 7E0BC0:6F they enable your car to go everywhere on the track map including outside the road without being harmed, loads of fun! That's pretty much what I have for now...I hope I didn't make any big mistakes. I'll let you speculate about what we could do with this... Metroid Cubed, Zelda Cubed, 100 Marios and other NES related Shockwave silliness are at: http://pages.infinit.net/voxel/home.htm (edited by VL-Tone on 06-06-04 08:59 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 3/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Here is the code that enables you to drive at 999kph in F-Zero 7E0B20:70 7E0B21:0E Always drive at 999Kph Also very fun especially with the speed code: 7E0BB0:1A 7E0D51:80 7E0BB1:00 7E0BC0:6F Cars can go anywhere off-road. Have fun! Metroid Cubed, Zelda Cubed, 100 Marios and other NES related Shockwave silliness are at: http://pages.infinit.net/voxel/home.htm VL-Tone ---Everything counts in large amounts--- |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 4/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Damn I'm stupid at times... I'm sure I verified that the data i found in RAM describing each panels with 16 rows, was not also in the ROM...uncompressed It seems that it's actually uncompressed just after the 32x16 maps!! Exactly where Heian-794 was fiddling around! (I found the horizontal line format before I read the post though) So just take my other post, and apply it to $36CD0 in the ROM instead of the RAM and ZST offsets. This is too cool! I thought that we would have to crack down the compression format and all... or make a ZST track editor... But no, a good old ROM track editor will do! Now forget the $38620 address for row tile definitions... it's actually part of the panel data.... I guess the row tile definition is compressed in RLE somewhere in the ROM because its at least 64k uncompressed with many tiles repeating. Metroid Cubed, Zelda Cubed, 100 Marios and other NES related Shockwave silliness are at: http://pages.infinit.net/voxel/home.htm VL-Tone ---Everything counts in large amounts--- (Edit: found out that the $38620 address meant nothing )(edited by VL-Tone on 06-05-04 05:06 PM) (edited by VL-Tone on 06-05-04 05:15 PM) (edited by VL-Tone on 06-06-04 08:59 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 5/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Well it's better than nothing I'm a little too enthusiastic about F-Zero being cracked it seems and didn't spent much time on that newbie post. Anyhow thanks for welcoming me By the way Acmlm you are credited in the help text of the very old and primitive online SMB2 editor (as well as BMF54123), just click on the mushroom. A little easter-egg for it to make it more useable, type doki doki in the big yellow text field and click Draw level (or load level I'm not sure anymore), it will load the data from level 1-1. As for the 3d Zelda 1, the version on the Metroid Cubed page is completely different that the one you saw a few time ago, it has been rebuilt from scratch and you can now rotate the playfield (at only 4 discrete angles though) and change the lighting in real-time. Oh well I don't know what to say anymore than that, I feel too much pressure Metroid Cubed, Zelda Cubed, 100 Marios and other NES related Shockwave silliness are at: http://pages.infinit.net/voxel/home.htm VL-Tone ---Everything counts in large amounts--- |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 6/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Sorry about the long lines, I didn't know it was a problem for some of you, I have no problems seeing all the lines even at 800x600. Heian-794 very cool data you have there. I'm not sure what you are talking about when you say the graphic data for the tiles are in genesis format in rom with a two-dot separrator. For some reason I don't have access to all of the Windows tools like tile layer pro, I can use DOS utilities though, I hope you can still see me as helpfull I used BGMapper to view and copy the tile graphic data, and with one of it's mode, they all show sequencially with no trace of a two-dot sepparator (do you mean 2 bytes?), and in the same order you describe. BGMapper opens ZST states so maybe the sepparator is not kept when copied to RAM. Bgmapper also have the very usefull ability to show and save the whole Mode-7 graphic plane (that include like 9 panels, some partial), and that's how Tyler extracted the panels graphics. If he didn't automate the process, it probably was very time consumming. Now using the same method, but creating new panels for the starting line for example. Those panels would be made of the numerical sequence of rows usable in that track. For example at first we would generate a panel with: 0040 1040 2040 3040 4040 5040 6040 7040 8040 9040 A040 B040 C040 D040 E040 F040 That would cover all the possible rows between $4000 and $40F0, 16 different rows. If we generate panels for all possible rows in Mute City, by modifiying a ZST, that would make around 90 different panels to do. If we modifiy all the panels visible in a "scene" from bgmapper we could get around 4 (probably more) panels showing a total of 64 different rows for each mode-7 plane. By saving the graphics for all these planes we would end up having the graphics for all the possible rows for a track, and we could make an editor just from that without having to crack the row definition format. That's actually how I did my own never finished Zelda 1 overworld editor years ago. But yes it would be ideal if we had the row def format, but I'm not sure editing the rows would be so simple as they are used all over the game and it would be hard to track down what is being affected by a change on a single row. Anyway the 4096 possible rows with the shifting can generate tens of thousands of possibilities, that should be enough i guess... I thought the $20x$2 rows were made of 2x2 (not 4x4...) TSA macro tiles, well guess what, I think I found where this data is (or maybe it's full row data but it doesn't look like it). I found it by searching for a $9A $9A $9A $9A sequence. This 2x2 tile definition starts at $64580. The 4 tiles have to be drawn in this order: top-left, down-left, top-right, down-right. The format seems to be more complicated than that since some macro tiles have a broken parts. and the data seems to be offseted at different places as you progress thru the data. Because tiles can be from $00 to $FF they couldn't fit extra data, so maybe some table elsewhere govern the way this data is read, enabling mirroring of 2 tiles to form a 4 tile macro tile and things like repetition and rotation of tiles. Anyway I'll let you look at it and try to figure it out. I used a custom tool to build these examples, the first one is from $64580 to $645AF. These are drawn four 8x8 pixel tiles at a time using the order I mentioned, 16 of them sequencially from left to right. Though some data seems to be arranged in row like fashion, I don't think its all the raw data for all the rows since it would take much more space than that. I looked all over the ROM and didn't find any other data that produced structured 2x2 tiles. There are much more good results than these examples though starting at $64580.         As for F-Zero 2, aside from the problems you have mentionned, one of the problem is the rarity of this rom. Another problem is that most people wanting a F-Zero editor want it for nostalgic reasons. Since not too many people ever had a BS system, it would limit the appeal and people would end up requesting one for F-Zero 1 anyway. So F-Zero 1 should be our priority, and F-Zero 2 as an extra. Anyway do whatever you feel, if F-Zero 2 makes you work harder to crack it, go ahead Metroid Cubed, Zelda Cubed, 100 Marios and other NES related Shockwave silliness are at: http://pages.infinit.net/voxel/home.htm VL-Tone ---Everything counts in large amounts--- (edited by VL-Tone on 06-06-04 05:22 PM) (edited by VL-Tone on 06-06-04 09:00 PM) (edited by VL-Tone on 06-07-04 11:00 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 7/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Thanks for all the kind comments from you... I keep forgetting that this board is not only about ROM hacking but still this is why I'm here Yeah cracking F-Zero is fun as tons of new info is discovered these days. I hope this leads to something, if not, I'll make the editor myself I also hope my finding in Starfox will create interest in cracking the level format. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 8/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| I'll just add that people currently experimenting with F-Zero 2 like Heian-794 shouldn't stop, continue your great work Most of the things found in FZ-2 will also apply to FZ-1. And comparing could help us understand both games. (edited by VL-Tone on 06-07-04 10:59 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 9/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Wow neat discoveries here Starting positions will be very usefull. As for the A.I. it would be great if we find it, but I like time trials on F-Zero and I'm sure I'm not the only one I didn't look for pointer tables yet, I'm not too familiar with the way the SNES translate pointers into rom locations. Can you shed any light on this? |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 10/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Ok sorry if I shroud this in mystery but I guess it's my way of doing Much more to come soon... Here is a little question for fans of the original Starfox : What is wrong in those 2 screenshots? (hint: it's not the jpeg artifacts)   |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 11/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Yeah 4d rulez These screenshots might be more interesting than the first ones... http://membres.lycos.fr/nes3d/STARFOX12.002.jpg http://membres.lycos.fr/nes3d/STARFOX12.007.jpg I changed the player's arwing into an enemy Yes the high poly arwing from the select and title screen is bigger, it's actually hard to see where you shoot, but this could be worked out. Anyway it's for the fun of it, you are invincible while playing with these. Note that you must use the Starfox version 1.2 for these to work. Patch the 16 bit value at 7E3186 and 7E3187 in WRAM with one of these values. You can replace the arwing with any enemy you want, this list is in the ROM. The list is used by the "view and rotate all enemies from the continue screen" trick. (hit select on controller 2 while on the continue screen. ) ---enemy list for Starfox Version 1.2 to be used at 7E3186 and 7E3187 D0 BC, 9C D0, F0 E5, 5C C4, 78 C4, CC C4, 58 C5, B0 C4, 3C C5, 94 C4, 60 E6, A8 DB, C4 DB, 24 D9, 2C C2, F0 C2, 0C C3, DC C7, 88 E3, 6C E3, C4 E2, 0C B7, D0 E6, 50 E3, 70 E2, C4 CD, 9C DE, A0 E4, 48 DE, CC BD, 38 DB, F4 E4, A4 E3, DC E3, 2C E5, 50 CE, 4C C8, 44 DF, D7 B9 Following the 16 bit value at 7E3186 are values for other states of the arwing like when you break a wing, have a shield ect. You can tranform it into different enemies by braking wings or taking a shield I have other discoveries to share, but I don't have much time now. At 7E0448 and 7E0449 in wram there is a pointer used by on-screen objects, it changes as you go thru the level there is other objects in the same format surrounding it. You can pick pointers from there with a watch point and use them to change your arwing into other object found in the game. Note that this 7E0448 is also used to define the rotating arwing object in the title screen. Following the 16-bit object pointer at 7E0448 (which is D0BC for the high poly arwing), are three16-bit values for each of the axis, x y and z, then 3 bytes for rotation on the x, y and z axis. (edited by Acmlm on 06-07-04 11:38 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 12/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| 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. Anyway have fun |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 13/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| 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. (edited by VL-Tone on 06-10-04 03:37 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 14/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| 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. As for displaying ram values, I know that for me SNES9x Custom for *cough* mac *cough* can show a ram value on-screen while you play, in hex or decimal and from 1 to 4 bytes long. I don't know if SNES9x on other platforms does the same thing, but I'm sure some Windows snes emu can do the same and probably with more options. Maybe someone here could tell which one(s). I can run the DOS version of zSNES but I didn't find a way to display ram value in the emu screen. 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://membres.lycos.fr/nes3d/MuteCityPath_HighByte.png http://membres.lycos.fr/nes3d/MuteCityPath_16bits.png http://membres.lycos.fr/nes3d/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. (edited by VL-Tone on 06-11-04 06:17 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 15/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| I tried your DW hack, neat The problem with the walls you can go through seems to be related to checkpoints. The rival cars seems to behave the same way (what I described is now even clearer to me). When you face a checkpoint you can go foward thru walls it seems, which is not a problem normally because the checkpoints are arranged on the track in a perpendicular way to the sides. So in the normal game you never have to face a wall and the next checkpoint at the same time. Without changing the chekpoints paths anyway editing seems to be pretty limited for now. I'm guessing that the checkpoints are also used by the game to see if you are going reverse. Edit: also the boost panel direction is probably related to the same checkpoints. (edited by VL-Tone on 06-11-04 09:06 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 16/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Wow Parasyte! That's really awesome what you did I had the idea once of doing some asm hack and get the whole map to be displayed when you hit pause. Maybe you could add that too? It shouldn't be too hard. My only really usefull and working asm hack in Metroid is a patch that enables just about any blocks to be destroyed. There is some limitations and glitches, you cannot use it in Tourian. Also bombing doesn't affect the blocks under Samus, unless they were destroyable in the original, and when the blocks reappear they have the wrong graphics.  You can get an IPS patch here: http://membres.lycos.fr/nes3d/METROID_ALL_BLOCKS.IPS Also while we're at it, I started a doc about the way item location data is stored. I had to figure out these by myself for Metroid Cubed, since it was not documented, and it's not obvious in the Metroid or MetEdit source codes. The doc is there: http://membres.lycos.fr/nes3d/MetroidItemData.txt Continue your great work Parasyte (edited by VL-Tone on 06-13-04 12:01 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 17/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| I forgot about the map size limitation. My first idea was simply to fetch the bytes from the 32x32 map into the name table (with some filter). But yeah I then realised it wouldn't fit on the screen. I have been thinking about showing only the current area. This could be achieved by having 1-bit masks (that would take 128 bytes) inserted in each area bank. An X Y offset would also be stored for each area so the area map is centered. Anyway it was just a thought and your mini-map is cool enough for me The ultimate Metroid asm hack ever imho would be a spider-ball... I know it would be very hard to pull this one up. A jump ball and space jump could be easier though. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 18/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Hmmm a sand pit room? In Metroid 1? I know every room by heart in Metroid, and I never seen a sand pit room... Thank you so much Parasyte for giving the source code with your hack. it singlehandledly made me want to do my first "real" ASM hack. I hope you didn't have a secret project involving wall-jumping in Metroid because ------->I worked out a way to implement wall-jumping in Metroid!! It has a few quirks, but it's surprisingly good (at least for me).  Here is the IPS patch to activate wall-jumping in Metroid: http://pages.infinit.net/voxel/MET-WJ.IPS and here is the source code: http://pages.infinit.net/voxel/met-wj.asm It uses 26 bytes, and could be shorter I guess. This patch cannot be used at the same time as the auto-map patch (sorry! I'll work this out). Note to Parasyte, I used your source code for these experiments, so the base address is the same, If I ever publish this officially, I'll make sure it doesn't overwrite the auto-map code. Could you suggest me another base address? Oh one last thing, with a multi-direction scroll, how will you deal with lava? Lava works only in horizontal rooms, and it works by checking if Samus is lower than the bottom two blocks height. (edited by VL-Tone on 06-12-04 11:59 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 19/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Really neato Parasyte I knew my hack was not ideal, I didn't know what routine made Samus jump, so I simply changed the vertical movement at $308. Anyway it was my first real ASM hack, I guess it was not too bad for a first one I'm really happy you improved it, knowing that I showed you the way I'm sure you could have done it all by yourself, but I guess my hack inspired you to actually do it. As for using the 4x4 block patterns tiles to draw the map, I also was thinking about it. It wouldn't add -that much- code, If you store the patterns in the right order, you can use 4-bits to adress the 16 patterns without any calculation. I remember doing this on my thrusty TRS-80 Color Computer 2 in the old days. I guess space is really tight in 196 bytes, but isn't there any other unused area in the ROM where we could store extra code? |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 20/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| That post maybe a little off topic since it is mainly about StarFox 1, maybe it needed it's own topic, but anyway... I've been trying to crack the StarFox level format for some time now, and I made some interesting discoveries. Some of you may call me crazy to try this game since it uses the FX chip, but I think that its simpler than you would think, after all the chip was designed by only one or two guys. I'm sure the FX chip isn't used to decompress everything in the game. I would guess that it's only used to decompress graphics. The textures used by the 3d system are uncompressed, the character dialog is too, in plain ascii. Aside from the dialog you can find these interesting strings in Starfox 1 (and in one of the early SF 2 betas). HOVER TANK WALKER REL AXIS REL AXIS DEMO GAME PAUSED REL AXIS LOADING BAY EMPTY NULL MISSILE1 MISSILE2 TLASER HMISSILE TM GUN MACH GUN LASER TRILASER SHOT GUN We all know that there is a Walker in Starfox 2 and a tank in SF 64, but this is Starfox 1 we are talking about... Also interesting is all the different weapon names. Maybe these could be activated? I wouldn't bet on that. Aside from the near Final SF2 beta, two other were leaked. One is a fake I'm pretty sure, I never had any success on playing it and really it's content doesn't look at all like 65c816 code. The other is the one with a walker and an all range mode. Wild guess but this could also be a Starfox 1 beta. From what I can deduce from what I read about the story behind Starfox, Argonaut wanted to do an all range mode game a la StarGlider II (StarFox direct ancester) but Nintendo and Miyamoto made them do a game on rail (which is not a bad thing in my opinion). Anyway now that I think of it, it doesn't make as much sense as I thought... Now as for what I discovered data-wise in Starfox 1. Unfortunatly for some reason some part of my discoveries apply to StarFox version 1.0 and some to 1.2. To differenciate the versions, the 1.0 version has bright red outline in the title screen logo, and version 1.2 logo has the same outline color more like dark red brown. At $284B There is a list of about 250 16-bit pointer begining with A1AC F8C0 20D3... These are pointers to a little more than half of the polygon objects used in the game. For example if you change all of these to $20D3 you'll find that almost all objects in the game have been changed to arwings! The actual data defining the general properties of these objects such as relative size and color set is 28 bytes long and found starting at $2E15 (substract $8000 and add $2E15 to the 16 bit pointers from $2848+ to get the actual ROM position). Note that these 28 bytes don't contain the polygon data, it's referenced by some pointer in this data. I documented almost all of these objects in this document: http://pages.infinit.net/voxel/STARFOX_OBJECTS.TXT This is from Starfox version 1.2 but only one byte seems to be different from version 1.0 in each 28 byte part. Note that in Starfox 2 final beta the equivalent data is in 30 bytes chunks and unlike SF 1 it doesn't have any break in it's continuity. My document is an early version and there are couple of mistakes and I dont know the name of all bosses by heart, but almost every object (around 400 of them) have a little description at the right of the hex. I'm still trying to figure out the details of these 28 bytes chunks but I found the basics of it, here is an example: Let's take the Normal arwing entry, actually there are three of them, one is used for the other characters ships, but lets take just one for the example. 73 F1 11 96 F1 00 00 00 B2 5D 24 00 0E 00 50 00 50 00 13 82 20 D3 20 D3 20 D3 20 D3 Normal arwing (version 1.2) 73 F1 11 96 F1 00 00 00 AC 5D 24 00 0E 00 50 00 50 00 13 82 20 D3 20 D3 20 D3 20 D3 Normal arwing (in version 1.0) -73 F1 11 96 F1- is some kind of pointer that refers to the polygon data,you can change it to another object pointer, for example 01 E0 0C 42 E0 for the normal sized high polygon arwing. In my previous hack I only found a bigger high poly arwing and the way I patched it made it so that any objects you changed your arwing into made it invicible. Now if you change the arwing in all 3 entries the way I just described it will act like the real one and you won't be invincible. As for the rest of the 28 bytes, I don't know what the -00 00 00 B2 5D 24- part is but I'm pretty sure that -00 0E 00 50 00 50 00 - defines the scale of the object in the 3 axis. -13 82- is the color set for this object. If you change it to ED 82 you'll get an Arwing with the blue part changed to orange/red. C1 83 will get you a gray arwing and 7C 80 a completely black one. After that -20 D3- is the "object pointer". Again do $2E15+$D320-$8000 to get the ROM address, which is actually where this line of data can be found, I don't know why it's included there since it's implicit, but it seems some objects have different offsets than their own stored there. The general rule is that you can take the last 2 bytes of the 28 bytes and it gives you the object pointer. Note that these pointers are the same that can be found at $284B in ROM. They are also to be found in part of the working RAM. At 7E0448 and 7E0449 in WRAM in version 1.2 is the pointer for the rotating arwing in the title screen. Version 1.2 in RAM 7E0448-7E0449 Title screen Arwing object pointer. 7E0450-7E0451 is a 16-bit value for it's X position 7E0452-7E0453 Y pos 7E0454-7E0455 Z pos (the arwing is constantly moving foward to go against the automatic level movement) 7E0456 one byte for the Z rotation 7E0457 Y rotation 7E0458 X rotation These values while playing as well as many other similar data slots in this RAM area will contains the data for the onscreen objects presumably used by the FX chip directly. The data changes as the objects are loaded and in a non predictable way depending on if you shoot or not and if objects disapear. While in the continue screen you can change the current object to another object by using cheats at $7E0020 and $7E0021. For example 7E0020:85 7E0021:AC set it to Andross in a cube. This bonus feature in the continue screen comes straight from StarGlider II. These objects (those in the the doc) though seems to be part of macro objects for example the big walking robots holding blue columns are built from 2 objects. I'm looking for this macro object description data since these are probably referenced by the actual level data. Which is itself segmented in steps or chunks. In version 1.0 at $7E16FF and $7E1700 in RAM is a 16-bits pointer. This pointer represents the next chunk of level to be loaded (a chunk is a "step" like in the SF2 debug menu). At $7E16FD and $7E16FE in RAM is a 16-bit countdown to 0 starting from a number which is different depending on the level chunk. When the timer reaches 0, the next level chunk from the pointer is loaded and the objects appear at the horizon. If you use a cheat to stop the timer you'll end up in a void, with no new objects appearing in sight. If you use a cheat to stop the timer at 0, almost all objects from a level will appear at the same time, and the game ends up slowing down to a complete halt because it can't handle that many polygons. If you use a cheat to set a specific 16-bit pointer at $7E16FF you can make part of a level loop endlessly. A funny example, if you go into Corneria level 2 and activate these two cheats, 7E16FF:BB and 7E1700:01, you'll loop the part where one of your crew member will get attacked by an enemy. With these cheats activated you'll end up with dozens of arwings chased by dozens of enemies, and with each time a new character will blable something about being attacked. Then again, unfortunatly, the game will end up slowing down to a crawl. You can actually skip to any part of the game instantly though some problem arise from playing a space level on the ground and vice-versa. To find valid pointers you can use a watch feature in your emulator and watch adresses at 7E16FF and 7E1700. At 7E1FF9 and 7E1FFA is a 16-bit pointer for the starting level pointer, you can use a cheat at this adress to start at any level in a more "normal" way. It doesn't change while you are playing, only when you start a new level from the select screen. Here is the data defining the level in a general way, something like "headers" for setting the weather, if it's a space level and other things. The values between ** are the level data pointers for 7E1FF9 and 7E1FFA, for example to start on the slot machine level use these cheats: 7E1FF9:E5 and 7E1FFA:48 At $1D874 in ROM in Starfox Version 1.0 --Level 3 Route (in order) >00 E6 00 03 04 14 00 *66 5D* 0D 58 01 04 4E 00 F8 FF FF >02 04 00 03 04 0E 03 *4C 5F* 0D 59 01 04 4E 00 F8 04 4E 00 F8 02 0E 08 F8 FF FF >01 32 00 03 09 08 05 *A7 5F* 0D 6A 01 02 0E 08 F8 02 0E 08 F8 02 0E 08 F8 03 0E 08 00 03 0E 08 00 FF FF >01 54 00 03 12 05 09 *2A 60* 0D 6B 01 03 0E 08 00 03 0E 08 00 03 0E 08 00 03 0E 08 00 FF FF >01 72 00 03 00 00 0F *85 60* 0D 72 01 FF FF --Level 1 Route >01 56 02 03 06 15 00 *68 50* 0D 58 00 02 0E 08 F8 FF FF >02 02 00 03 0B 11 02 *68 52* 0D 59 00 02 0E 08 F8 02 0E 08 F8 02 0E 08 F8 03 0E 08 00 03 0E 08 00 FF FF >01 B4 00 03 14 0E 06 *C3 52* 0D 5A 00 03 0E 08 00 FF FF >01 C6 00 03 18 0B 08 *86 55* 0D 5B 00 04 4E 00 F8 FF FF >01 D8 00 03 00 00 0F *02 56* 0D 5C 00 FF FF --Level 2 Route >01 62 02 03 06 17 00 *CF 63* 0D 6C 02 03 0E 08 00 03 0E 08 00 FF FF >02 00 00 03 0C 15 01 *F6 65* 0D 6D 02 02 0E 08 F8 02 0E 08 F8 FF FF >01 12 01 03 12 13 04 *51 66* 0D 6E 02 03 0E 08 00 03 0E 08 00 03 0E 08 00 03 0E 08 00 03 0E 08 00 FF FF >01 34 01 03 1B 13 07 *D8 66* 0D 6F 02 02 0E 08 F8 04 4E 00 F8 FF FF >01 4A 01 03 1C 0B 0B *1C 68* 0D 70 02 04 4E 00 F8 FF FF >01 5C 01 03 00 00 0F *B9 68* 0D 74 02 FF FF >01 4A 02 03 06 0F 03 *4C 5F* 0D 59 01 00 0E 08 F8 00 0E 08 F8 00 0E 08 F8 FF FF --Black hole >02 06 00 03 0C 09 0A *A9 48* 0D 71 00 00 0E 08 F8 00 0E 08 F8 FF FF >01 54 00 03 0D 0B 0A *A9 48* 0D 71 00 00 0E 08 00 00 0E 08 00 00 0E 08 F8 00 0E 08 F8 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 FF FF >01 D8 00 03 0B 0E 0A *A9 48* 0D 71 00 00 0E 08 08 00 0E 08 08 00 0E 08 08 00 0E 08 08 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 FF FF --Two levels repeated from routes with some different parameters >01 34 01 03 09 10 02 *68 52* 0D 59 00 00 0E 00 F8 00 0E 00 F8 00 0E 08 F8 FF FF >02 06 00 03 0C 19 01 *F6 65* 0D 6D 02 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 00 0E 08 00 FF FF --Venom levels >01 6E 02 03 00 00 0F *29 69* 0D FF FF >00 03 00 00 0F *F5 60* 0D FF FF >00 03 00 00 0F *7F 56* 0D FF FF --Out of this world (slot machine) >00 03 00 00 0E *E5 48* 0D 73 00 FF FF Let's recapitulate, The levels in Starfox are segmented in chunks containing macro objects that include scenery, enemy and scenario events like ending a level or a crew ship being attacked.These macro objects are constructed from any of the 400 polygonal objects. The polygon data includes animation features. What I'm missing is the level data, the macro object data and the polygon data.Actually I know approximatly where the level data is, but I can't figure out it's format I would need to find a correlation between bytes and part of a level. My research may eventually lead to a dead end, but anyway I did this mainly for my own "fun". One last thing, anyone ever played X (Xekkusu) for the Gameboy? It's a polygon game unreleased in the US (was to be called LunarChase). It includes some big names in the credits like Miyamoto and Hip Tanaka, and Dylan Cuthbert (who was Starfox 1 and 2 main programmer). It's a little primitive but the title screen demo is cool, I can't get past the training though, it's all in Japanese and it looks like I always fail the 3rd mission. |
| Pages: 1 2 3 4 5 6 7 8 9 10 |
| Acmlm's Board - I2 Archive - - Posts by VL-Tone |
