[SM] Editing Samus

[A_red_monk_called_Key]

Holy Sh#T it can be done!


now if only i can find a way to turn the beam into a whip

[Crashtour99]

Yeah, all the data is in $92 (except for the gfx of course).  It's just a bear to search through and find everything you need.

[A_red_monk_called_Key]

yeah i've been messing with bank $92 off and on since last spring. this was easy[spoiler]Marioid[/spoiler]

but this[spoiler][/spoiler] uses 4 different blocks of 16 different tiles that can be put into any position

[Crashtour99]

Yep, that's the basic format behind Samus' gfx for each half (top half and bottom half), though not all animations will use all $F tiles worth of gfx for each half.

[A_red_monk_called_Key]

what? i'm confused. i use only a 4 part animation

04 00
E0 C3 F8 00 28
F0 C3 F8 02 28
00 C2 F8 04 28
10 C2 F8 06 28
this part   ^ was the trick (in correlation with the 2nd half of the GFX pointer) ($100 for both to get 16 tiles)

[Crashtour99]

I think we're talking about different things.  LOL  I'm thinking I'll try writing up a guide or something this week detailing in depth what's going on in Samus' animations and how to edit them.

But basically, Samus' graphics come in 4 parts.  There are DMA pointers and part sizes for each half, top and bottom, and each half has 2 parts (not exceeding $100 bytes, because that's how they're formatted and stored in VRAM).  Each half has it's own tilemap (like what you've written above) that uses the gfx as they appear in VRAM.  So there's a top half tilemap, and a bottom half tilemap.

What you have there, is the tilemap for Samus' top half, using the 2 parts of the top half gfx.   :wink:

[A_red_monk_called_Key]

I think we're talking about different things.

yes i'm under the impression that we may have different understanding on the subject. i have traced all animations in hex and with gigger. i have a good under standing for the data in bank $92 and am almost done with my document (just have grapple animations to do) i'll try to get this done soon(i might have different info). but i only know about 3 parts at the moment unless you count twice for top and bottom halfs, then i know 6 parts(i'm talking about including pointer table because it displays GFX for split second and jumps around). all the data is hard to keep track of and thats kind of what i did with my doc.

[Crashtour99]

So you've documented pretty much the entire bank?!?!  Wow, that's a ton of stuff to sift through.  Between the DMA pointers, animation progression tables (that serve as an index for which DMA pointer to use), the tilemap pointer tables, and the tilemaps themselves, I can definitely see it being a big mess.  This could be a very valuable resource though.  I imagine making it into a fully assembleable file kinda like Kej's pose transition table .asm and reorganizing it with labels and such so it's easier to understand.

I'll definitely be looking forward to seeing it.   :yay:

[A_red_monk_called_Key]

So you've documented pretty much the entire bank?!?!  Wow, that's a ton of stuff to sift through.  Between the DMA pointers, animation progression tables (that serve as an index for which DMA pointer to use), the tilemap pointer tables, and the tilemaps themselves, I can definitely see it being a big mess.  This could be a very valuable resource though.  I imagine making it into a fully assembleable file kinda like Kej's pose transition table .asm and reorganizing it with labels and such so it's easier to understand.

I'll definitely be looking forward to seeing it.   :yay:

i'm trying to doc all the data so i can rewright $92. there is only one chunk of data i don't know how to move yet. im sure i can find or your doc will have the answer i need.

i don't know what you mean by DMA is it this (00 80 9D C0 00 80 00) data ner $95000ish. as far as i know bank $92 has 3 parts. first is the animation pointer tables, then animation data, then the GFX pointers.

sure i can convert in to an ASM file no problem.

[Crashtour99]

Yep, that's the DMA info ( [long pointer to gfx][part1 size][part2 size] ).  The pointer to that is stored to 7E:071F and 7E:0721 for use when all the gfx are transferred to VRAM for the updates (once per frame).

If you take a look at the spinjump animation improvement patch I put in the collab thread you'll see the animation progression tables (long columns with 4 bytes each).  The 2nd byte is the index for which DMA pointer to use for the top gfx, the 4th byte is same, but for bottom gfx.  Not exactly sure what the 1st and 3rd bytes are for, but I think they're related to some other sort of indexing.

Tilemap tables and tilemaps you already know all about.  haha   

[A_red_monk_called_Key]

where is this data(in the ROM). i'll try messing with it to see what it does.

[Crashtour99]

where is this data(in the ROM). i'll try messing with it to see what it does.

Easiest way to find it is by setting breakpoints on these in a debugger:
$92/8016 BD 4E D9    LDA $D94E,x[$92:D984]   A:0036 X:0036 Y:C4EC
$92/8051 BD 4E D9    LDA $D94E,x[$92:D984]   A:0036 X:0036 Y:0014
(these are from when I was looking at spinjumping animations)

What you want is the location in brackets.  At that location is a pointer, the data where the pointer points to is the table that determines which DMA pointer to store to RAM for the VRAM updates.  The pointer itself is loaded into A, then $14 (direct page RAM, which when this is running holds the current frame number of the animation) is added, and that's used as an index for loading DMA pointers from the relevant table.  To my knowledge though, only the 2nd and 4th bytes from each 4 byte string are used in this routine, so I don't know if the 1st and 3rd bytes do much, if anything.

[A_red_monk_called_Key]

i just found it

-----------------------------> STAND
D0B0 =
D1C8 =

DOB7 =
D200 =

D0BE =
D207 =


[$92:A072]
[$92:ADBB]
[$92:A088]
[$92:AE98]
[$92:A09E]
[$92:AEA9]


TOP HALF POINTERS
$903C1  $0008
72 A0  88 A0  9E A0  88 A0

BOTTOM HALF POINTERS
$909E1  $0008
BB AD  98 AE  A9 AE  98 AE

$92/801D BD 00 00    LDA $0000,x[$92:DB48]
$92/801D BD 00 00    LDA $0000,x[$92:DB4C]
$92/801D BD 00 00    LDA $0000,x[$92:DB50]
$92/801D BD 00 00    LDA $0000,x[$92:DB54]



i finished copying bank $92 an found data at $95B48, if broken up into 4's it shows a pattern.

the data is executed at $92/801D is awesome. and the mystery is salved 00 20 is the same as 01 00. so in stead of going to $20 they go to $01 $00 to use the next DMA. they both work but none of the original ones go over $1F so i wouldn't try $20