 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,524,625 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-03-24 05:04 PM |
|
| Guest: Register | Login | |||
| Main - Posts by smkdan |
| smkdan |
| ||
 Ninji Level: 36 Posts: 1/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
Here's a few quick observations.
The upper bits that are OR'd with the 4pp tiles to get your 256 colour tile are stored at 7F:C000-7F:C0FF after they're pulled from ROM. They only have the upper 4 bits set ofcourse. $8481CA holds the upper 4 bits that are ORd with the 4bpp tile 00. (SNES address or 481CA ROM address). According to your doc this lands it in the mariocircuit GFX area. I changed 481CA to 10 and it turned tile 00 to orange. The SMK palette page shows orange just below the grass colours so it makes sense I suppose. I changed the next byte that didn't destroy the track entirely (481CD) and it changed alot of tiles to the orange palette. 481CC seems to hold the value it repeats for (41h + 1 = 66 tiles), they're mostly track / sand tiles. 
oh and goodluck with that editor. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 2/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
I just remembered. When I decompressed some track graphics I noticed there were some dummy tiles right at the start. 256 bytes; thats 8 4bpp tiles or 4 8bpp tiles. There's your palette bytes right there.
So yeah, they're stored at the start of each compressed hunk of track graphics, in just the same format. I don't know much about the compression format it actually uses. I don't rmemeber seeing any documentation in the lunar compress zip. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 3/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
No worries.
Speaking of palette pointers, I have the 24-bit pointers that point to the actual palettes themselves. Stifu, this might be a good addition to your compilation since modifying these with an expanded ROM means no real size restrictions. They start at 0x1EDB8 for a headered ROM and span 3 bytes for each track ofcourse (the first is for Rainbow Road). Say for Mario Circuit... IE: 1EBBE: 11 1EBBF: 7F 1EBC0: C4 C4:7F11 SNES perspective / 47F11 ROM. You can just stick your oversize palette in the end of the ROM space that TrackDes probably won't use, or you can just expand the ROM yourself. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 4/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
I saw different GFX from TT select screen so I thought it was part of the palettes aswell. yeah I got this one from around the earlier part of the year. I'll get myself the updated one. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 5/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
I hear this is a very common SPC player used in alot of in house SNES games. I've been collecting notes on offsets of F-Zero and how it operates, and I'm not sure if I remember any mentions of it in a previous thread but I'd like to play with the music / SFX side of things. There was a music hacking thread a fair while back, so i'm guessing someone has to have some documentation on the commands the SNES has to write to 2140-2143 to do its work.
Thanks, |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 6/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
what do you mean Raccoon Sam? All the tracks have different tilemaps.
I would really like to find out how the track sprites are stored. It looks hideous having pillars supported nothing, thwomps on lava and pipes and moles in ridiculous places. I found some pipe related data btw. Here are some of the addresses it feeds to the DSP-1 for command #6 (object projection calculation). This is for one of the mario circuit pipes. 2 bytes each. It's what the dev manual says anyway. 7e:1818 = X (7e:1816) 7e:181c = Y (7e:181A) 7e:181f = Z The output X and Y eventually end up in sprite RAM. Bracketed addresses hold data which is used to operate on the X and Y variables. Haven't messed with enough to find what they do. These values initially hold values pulled from the ROM. Changing X and Y to all FF gets this. Z didn't do anything when I messed with it. Seems to be relative to the bottom right... 
I'm off to bed; I'll find more about it later on. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 7/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
I can confirm a few object notes. I played with the pipe again today and found the following.
The positions in RAM are relative to the top left, not bottom right. X has a maximum value of 3FF as does Y. 1FF would land it in the middle of the appropriate axis. I did not change the Z paramater but the pipes still bounce karts off it and appear at a proper size. The values I mentioned that operate on it before the DSP-1 does its stuff can be left alone to modify their positions. Here I changed X to 000 and Y to 3FF. As explained, it appears at the very tip of the track. 
X = 3FF Y = 000 
X = 3FF Y = 3FF 
With any luck, the other track objects follow a similar format and you'd have an object relocator included in that editor of yours. Now to find where in ROM they're stored... EDIT: I added one too many F's... |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 8/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
I'd appreciate that Keitaro. F-Zero is one of the launch titles so with any hope it'll have less commands than later titles. I'll note those 2140 writes, since I'm looking for commands in particular. Don't want to get into hacking the SPC routines or anything right now. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 9/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
If only it was that easy. First thing I tried, then realised the matches didn't turn out to be the pipe data at all. There's some weirdness thrown into the mix.
Here's a snippet. It's storing the X and Y (not the registers) to the mentioned memory locations above. That first line is what it pulls from the ROM. LDA [$08],y[$85:C9C0] PHA AND #$007F ASL A ASL A ASL A ADC $0FC6 [$84:0FC6] STA $18,x [$00:1818] PLA AND #$FF80 LSR A LSR A LSR A LSR A ADC $0FC6 [$84:0FC6] STA $1C,x [$00:181C] I'm not sure if you know 65816 so here's a run down. 7e:0fc6 holds a constant of 4 on all tracks except Donut Plains which holds 10. X = Take 85:C9C0, drop all but the 7 low bits, multiply by 8, add 4 *or* 10. Y = Take 85:C9C0, divide by 16, drop the low 3 bits and add 4 *or* 10 to it. C9C0 spans two bytes ofcourse. No, I don't know why it does this. It just...does. Hey, maybe they wanted to squeeze 4 bytes out of their 2? I hope so, and there isn't something deeper to it. A collection of pipe data is around 85:C9C0 packed cloesly together. Notice how when you move away from a collection of track sprites, they vanish and new ones take their place? They fill up the X and Y object RAM whenever a new section of the track is entered, so it's not all loaded at once. This means that the 'object clusters' need to be accounted for, as only a handful of track sprites will be selected for display at any given time. Oh and yes, the same routine and same format applies to other track sprites aswell. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 10/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
The data won't look similar because the X and Y for objects are mish mashed together, plus the factor of human error. Later on I think I'll replace the wierd 7 bits precison X Y storage to a 10 bit precision routine. It would make editing it a fair bit less irritating and the extra precision can't hurt. i'll get a start on logging object locations today. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 11/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
Here's a few quick ones before I sleep. Change the data to 00 or something and you'll see what I mean with the grouping. Or try changing it according to the format on the first page. Bit messy though. I'll do the rest tomorrow; easiest logging I've done recently.
MC, DP and BC use the same routine while GV uses a slightly modified routine and format, but it's not much different. 84DC54 X store 84DC61 Y store MC1 Pipes 1 85:C9C0 85:C9C2 85:C9C4 85:C9C6 MC1 Pipes 2 85:C9C8 85:C9CA 85:C9CC 85:C9CE DP1 Pipes 1 85:CCC0 85:CCC2 85:CCC4 85:CCC6 DP1 Pipes 2 85:CCC8 85:CCCA 85:CCCC 85:CCCE DP1 Pipes 3 85:CCD0 85:CCD2 85:CCD4 85:CCD6 ---------------- 84DCCE X store 84DCDC Y store GV1 Pillars 1 84DD1D 84DD1F 84DD21 I know only C, but what problems do you have with display? Windows isn't handling your bitmaps the way you'd reckon? EDIT: stupid smileys.. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 12/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
GltichCog: They're stored relative to the top left of the track. Simply put, the low 7 bits of the 16 bit values I posted are the X position. The high 7 bits are the Y position. The highest 2 bits should not be used at all. Effectively, you have 128x128 positions as they're stored in ROM, although they're expanded to 10 bit proportions before the game uses them.
Ghost Valley has it's quirks in that it uses 8 bits precision for X and Y storage (256x256). I'm expecting something weird for cheep cheeps on koopa beach. Dirtbag: I'm doing this for Kart simply because it's something that needed to be found out for years now. Ridiculous object positions in track hacks should be over eventually. I'm doing this for F-Zero too, wiht hopes of writing an eventual editor. I have a good grasp on how the tracks are managed by the game, it's just the stuff that happens between taking the coordinates of your car and building the track has several layers of indirection that obscure it's format... Stifu: I wouldn't mind being a beta tester at all. Thanks. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 13/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
I don't get what you're saying dirtbag. The '?' blocks and coins are an extra overlay that's applied to the track in GP and Match. 8 bits vs 7 bits just means that there are smaller gaps between one value and the next, allowing more possibilities for placement.
edit: I have mushroom cup on my site now. http://smkdan.eludevisibility.org/smk.html |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 14/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
HDMA's are timed DMA transfers that go off on certain scanlines for selected channels (8 of them). Usually for special affects like changing the scroll values in the middle of the frame to get split screen, or in this case it's changing a palette byte to a gradually darker green over successive scanlines to get that gradient affect.
I guess you might be limited in avaliable channels for a certain game. I'm working with mode 7 racers which require 4 just for the track. SMK has only one HDMA channel that isn't used. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 15/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
Ok I finished with the objects. All locations for all tracks are documented. I seperated Ghost Valley from the table as it diverts from the 4 sets of 4 objects system. There's still the ranges and that 150cc dropping of objects though.
For now, I have plenty of notes for F-Zero that I'd like to write up. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 16/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
The game doesn't seem to care. All the garbage is still put into VRAM, just the tilemaps never touch them. No clue why they'd decide to put music in there. Can you tell me the compression it uses, or are you using the .DLL to do it? Sticking another FF after the the first at the end of the GFX (It does have one! It's at 499FF headered) seems to stop the garbage overflow when viewing in YY, without destroying the title music, but there's still garbage put into VRAM for whatever reason. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 17/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
It's possible to leave the original overlapped data as it is and put the newly compressed data in an expanded area of the ROM. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 18/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
I think automated graphics exporting / importing would be a very nice feature.
-User 'exports bin' for a certain selection of graphics. -User 'imports bin' and compressed sizes are calculated for the importing GFX and GFX currently in ROM. User is prompted if the new size exceeds old size to expand the ROM and modify pointers. I never did anything serious with lunar magic but it did something along the lines of that. Beats keeping a list of pointers and sizes whenever you want to try new GFX or something. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 19/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
There's defintely something funky with the palettes that haven't been completed. They keep changing after I select a course, then select another, then select that course again (Time Trial I mean). From that, I'm just taking a guess that it's not LC / your program at fault. |
| smkdan |
| ||
|
Ninji Level: 36 Posts: 20/238 EXP: 288818 Next: 19292 Since: 05-26-07 Last post: 4070 days Last view: 4019 days |
There's alot of data on the to-do list, but I got a lead on the track overlays.
Try going to 5DB00 (headerless again). This here applies to Battle Course 1. The first byte controls what tile is to be overlaid i.e. 10 would produce a slick instead of a Q block of whatever angle it was (there's different values for different rotations of Q blocks). The next 2 bytes are an index into 7F:0000; the storage area the game uses for the tilemap bytes. The game looks up this table and overwrites the appropriate tilemap bytes into the index specified. Keeps running through the table until it hits double FF. This is just what it seems though, try messing around with it a bit. I'll try to figure out the rest later. Here's a pic of all the indexes moved to 00. They no longer appear in their specified spot. All moved to the corner.  |
| Main - Posts by smkdan |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 128, rows: 160/160, time: 0.221 seconds. |