 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,596,871 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-18-24 03:53 AM |
|
| Guest: Register | Login | |||
| Main - Posts by smkdan |
| smkdan |
| ||
 Ninji Level: 36 Posts: 21/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Thanks dirtbag. Yeah they're stored entirely seperate and in different formats. Trackdes doesn't touch them at all.
Stifu: I know the window style imples it, but the track view sizes to the proportions of the window, right? |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 22/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Got the rest of the overlay stuff on the site. I'll put pictures of each overlay set later. Basically it uses a base coordinate in the track tilemap to place a certain array of tilemap bytes to construct the Q blocks, coin arrays etc.
|
| smkdan |
| ||
|
Ninji Level: 36 Posts: 23/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
VSNES tells me SMK uses 4 8x8 sprites for the logo. There's nothing else on the screen at the time. It'll need some hacking to work out. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 24/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Anyone got data on it? I'd really like to find out some more about the track format in particular, but anything would be nice. I still have to have a more indepth look at the track formulas but I can say a few things about it. Here's what I've published for now. It's much better than having random notes scribbled in a .txt
http://smkdan.eludevisibility.org/fzero.html |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 25/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Thanks for the lengthy reply. I gave that idea a shot and it worked pretty well actually.
I never thought of doing that...Well, it looks my confusion about sharing tracks is over. You even see bits of the other track in-game if you go right to the edge. It's easy to pick out the tracks on all except ones that have more complex non - driveable areas like Whiteland. You say you made an alternative Death Wind but the computer wouldn't let you get by? How did it do that? Was it like the anti-shortcut thing on Port Town that takes you back to a particular spot if you try to jump the track? 32x32 panels...that sounds about right. You mean each byte in that 512byte table refers to a panel right? That makes the track at most 8192 pixels tall and 4096 pixels wide. The way I'm seeing it is that the game stores different panels for each track set (7F:5000-7F:FFFF), and these panels are constructed out of smaller, simpler panels (7F:0000-7F:24FF shared globally). I tried those patches on my (J) and (U) ROMs but I can't notice any difference in game. I stripped the header but that causes it to not start up at all. Is it suppose to have that wierd 3.92MB filesize after the patch? |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 26/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
You mentioned 32x2 tiles, which is true for part of it. The game is loading an array of 2x2 tiles for every 2 bytes in the deepest part of the panel map.
Table #2 on my site has entries, which when indexed by the Y posiiton, point to a row of tiles on table #3. It's effectively a row selector. Table #3 (indexed by the X position much like table #2 does for Y) points to the tile pool (0000-24FF), of which it then pulls 2x2 tiles, and proceeds (up to 16 times) until the buffers to VRAM are filled or until the byte index overflows from 32 of which it then moves onto the next panel and reloads the pointers. So..every entry in table #2 corresponds to 32x2 tiles, and every entry in table #3 corresponds to 2x2 tiles. That explains the huge size difference, and why Nintendo used a bit of compression there. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 27/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Did that site have any documentation? Would also be nice to have something to compare to when generating panels from collected notes.
Sounds like a first thing to try, but did you try a search relative for those names? I think I got a solid handle on the track format. The track data for table #3 itself is compressed. The highest 2 bits provide a portion of another pointer. These byte pairs a shifted down with the AA - FF bits ending up creating another byte pair. XXXXXXXXXXXXXX88 XXXXXXXXXXXXXX99 ... XXXXXXXXXXXXXXFF Then, it writes these 2 bytes in the next spot. FFEEDDCCBBAA9988 Every 16 bytes in ROM yeilds 18 bytes in RAM. Only 14 bits are required to index the whole tile pool (0000-24FF). FF up there obviously isn't used. To expand on the previous post, I'm pretty confident on the track format it's using. Every 32x32 panel has: 16 2byte entries for every set of 32x2 rows in the panel (Table #2) Each row has 16 2byte entries which point to the tilepool arrays. Each entry represents 2x2 tiles (Table #3) Each panel therefore has 256 (16x16, since each entry in table #3 represents 2x2 tiles) 2byte entries total which point to the tilepool arrays The upside of doing it this way means 32x2 rows can be reused many times. The tilepool represents 2x2 tiles; this is because the buffers represent 128x2 tilemap bytes. The game runs through a loop reading the 2x2 tiles from the tilepool 64 times to fill the 128x2 tilemap buffer entirely. The tilepool 2x2 tiles are arranged in a way where Byte1: Top left corner Byte2: Bottom left corner Byte3: Top right corner Byte4: Bottom right corner -- Yeah, physics would be nice. I'd like to get Green Amazone in there since it had really nice drift physics, but only one track with corners to use it. Guy, I think we have enough to start really getting into it. I've looked at the horizontal and vertical updaters and they all show code which fits right into the format I describe. All the Track, conditional track modifiers and pointers are all sorted. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 28/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
I don't have anything new my PM box; must've got lost.
Nice work. Paths really need to get sorted because reverse detection, arrow boost function and your only competition rely on it. I hope they all rely on the same set of values anyway. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 29/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Here's the start coordinates from one of my logs. Again, they're headerless. 2 Bytes each. I noticed changing the AI in those ranges breaks collision for your car, and changing these also breaks the collision...
X, Y BigBlue: 16005, 16007 Sand Ocean: 1600F, 16011 Silence: 16019, 1601B Port Town1: 1602C, 1602E Port Town2: 1603F, 16041 DeathWind1: 16049, 1604B DeathWind2: 16053, 1655 Red Canyon1: 1606F, 16071 Red Canyon2: 16082, 16084 Fire Field: 1608C, 1608E MuteCity1: 1609F, 160A1 MuteCity2: 160BB, 160BD MuteCity3: 160E0, 160E2 WhiteLand2: 160EA, 160EC WhiteLand1: 160F4, 160F6 |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 30/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
You're right Guy? (if i may toss in my 2c, this anonymous crap is beyond retarded). Before the AI data is stored into RAM, it adds the previous 16bits that came before it, or in the case of the very first entry, the starting coordinate. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 31/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Awesome post VL-Tone. Never noticed a thread in the archives...
A few more notes: -X coordinate AI begins at 7E:11FE in RAM -Y coordinate AI begins at 7E:13FE in RAM (I'm not sure how you got that address, VL-Tone) The above 2 addresses hold their respective starting coordinates. Loaded AI that's been operated upon is stored at 7E:1200 and 7E:1400 respectively. The AI points seem to be portioned into 2 parts... Length counters are stored as 1byte value. It's the high byte of a 16bit value where I'm not so sure of what it's doing to the other byte. For mute city 1 it's stored at 1609D (1700h) for the first, and 160A6 for the second (0600). That makes for 17h + 6 = 29 X and Y coords. Looks like you got it right. It carries on from where it left off. Nice to see people really getting into this. Might be closer than ever to getting it sorted. EDIT: Forgot to mention, AI for Mute City runs from Part one (17h) 174A3 - 174BA X 174DE - 174F5 Y Between transitions it loads these 16bit X and Y values and sticks them in the next spot. 160A8 X 160AA Y And this carries right on. Part two (06h) 17695 - 1769B X 1769C - 176A2 Y So, it's actually 30 points in Mute City 1 if you count the 'middle values' up there. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 32/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
I spoke too soon, there's more of it. 1B more 'coordinates'. When you destroy the coordinates I listed before, it seems to turn around and head to the large diagonal straight, and it turns away and heads there again when it reaches just before the finish line.
Part one (17h) 174A3 - 174BA X 174DE - 174F5 Y Middle Value 1 160A8 X 160AA Y Part two (06h) 17695 - 1769B X 1769C - 176A2 Y Middle Value 2 160B1 X 160B3 Y Part 3 (1Bh more) 174C2 - 174DD X 174FD - 17518 Y I see what the other 16bits than comes with the length counter does. It's an index added to the base ROM address supplied during the start and between transitions. The value is 3A1Fh, where 3A is the length counter and 1F is the index. Because it's this that's compared to the length (Part two had 0600h for example), 3A-1F=1B is the actual length. Changing everything here effectively destroys all the last remnants the AI had, the car does nothing that hints it knows the track. I changed to all 00's. I said that the car drove to the diagonal straight when one of these parts was modified, well reverse detection just happens to kick in here the moment you enter the area. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 33/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
If I saw that topic in the archives I probably wouldn't have made this thread. Spent a fair bit of time reinventing the wheel.
Heian, I put what I hope to be a fair description of the track format on my site (first post). Everything is in place, it even conforms to VL-Tone's posts in the archive. I hope it makes sense to someone. Conditional course modifications are up there too. 2x2 panels / 64x64 tiles are changed per entry. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 34/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Guy I'm a bit confused on how you generated that data. I listed 3 'sections' of AI data. What ranges of them did you use? X and Y are stored differently from what i'm seeing. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 35/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
I don't know how I missed this...
1) When you bump into the wall, the game repels you towards the "next" point along the way. That explains why changing these points / starting coordinate ruined collision. If the next point closest to you was out of range, you'd be dragged along the 'nothingness' following the same path as the AI. I picked the Wild Goose for the extra mileage and followed the rival car into the nothingness and as I got pulled in I followed my rival, even changing direction when my rival did. EDIT: I got a graphing program suited for it, so here's a Mute City 1 AI map from RAM. They're plain enough coordinates to plot from. As stated before, there's 59 points. 7E:1200-1274: X coord words 7E:1400-1474: Y coord words 
I understand how they're stored in ROM (8 bits exapanded to 11 excluding 'middle bytes') , just makes me wonder why the segmented it like that. Doesn't look like a very hack friendly layout. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 36/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
I don't know if neviksti's code changed since I looked at it, but I noticed a couple things. You don't seem to be (in the section 'PROGRAM CODE')...
-specifing a BG Mode ($2105) -enabling your chosen layers on the main screen ($212C) -setting the tile data address for your selected BGs ($210B for 1/2) -setting the tilemap address for your selected BGs ($2107 for #1) anomie has a really good reference for this at romhacking.net. One thing caught me out before; insert a TAB before your macros or WLA will ignore them without warning. Atleast that's what happened to me. Looks like you need to set up a tilemap too. All the info is in regs.txt. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 37/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Guess I neglected the first page a bit. Anyway, I got a solid handle on the path data. There's some stuff it's loading along with it that I'm not sure what it plans to do with it, but most of the stuff that effects the path is sorted. A 'master table' per track which has say, 3 entries for Mute City 1 (3 segments), each of which have length counters / indexes, 'Middle values' shown earlier, a pointer to a subtable to get the X and Y offsets in ROM along with some other stuff and a byte which signifies that the load is complete (non zero on real tables).
For the format, the game is treating bytes as if they're signed. Quick example: 7F: 7F << 3 = 3F8. 'Positive'. It simply adds that to the last value. 80: 80 is 'negative', it first sets all the high bits. Now you have FF80. FF80 << 3 = FC00 when trimmed. This is simply added to the last value. If the last value was 1000h, you'd get C00h. A byte in ROM of 80 would effectively subtract 400h, one of FF would subtract 8. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 38/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
I've uploaded a work in progress write up of the path data under 'Checkpoints'. The main table for Mute City 1 is at 1609A headerless. All the data for loading the path and how it is done stems from this table. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 39/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
Tables 1 and 2 appear in RAM as you see them in ROM. Table 3 is compressed. Every 16bits in ROM that corresponds to table 3 has 2 bits belonging to another entry that's unpacked when storing to RAM. It's pretty simple but I see it being very frustrating working on it solely with hex. A visual editor + decompressor would be really handy for that.
It looks like you got it right Heian. If it was stored in simple 8x8 fashion (1024 x 512 tiles), it would be just as big as the ROM image itself. The reusable style cuts it down to 23k~ for the Mute City set for example. And what we course-makers might want to do is to re-arrange these 'macro-tiles' (keeping their structure intact) into new rows, and/or re-arranging existing rows into new panels? That's about right. I envision a panel editor, which decomposes panels to 32x2 rows, which allows the user to select 2x2 tiles from the global tile pool to construct new rows, and to construct new panels from these new rows. Luckily, it uses 24bit pointers so you can relocate the track data if you want to exceed the size of an original track. One concern I have is the 16bit pointers for just about everything else. For variable length data like the path points it's a real concern. You're confined to a 32k space of which you don't have much room to work with. The loaders would need to be re written to allow for a 24bit pointers for any real flexibility (i.e. you don't impose a maximum of 3A points for Mute City or 63 for Port Town). SMK is really flexible in this regard since it uses 24bit pointers for just about everything. You could expand the ROM to 4MB and happily stick whatever you please whereever you please. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 40/238 EXP: 289155 Next: 18955 Since: 05-26-07 Last post: 4084 days Last view: 4033 days |
I'm putting most of my hacking time into f-zero but I still like to find smk stuff on the side. I put up starting positions a while ago, but the lack of AI / checkpoint info means it's kind of useless. Is there a topic in (one of?) the archives that went anywhere in that area?
Goodluck with the rewrite. I've never touched C# but if it means a more maintainable program than it'll be defintely worth the wait. |
| Main - Posts by smkdan |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 129, rows: 161/161, time: 0.237 seconds. |