Animation frames extension help

I was looking to add more fluid animations for my hack, for Sonic at least. I wanted to extend his frames for his rolling animation so it would go from /monthly_04_2013/post-2331-0-44152900-1366674383.gif to /monthly_04_2013/post-2331-0-12987400-1366674342.gif. I added sprites in SonMapEd and saved his mappings and pattern cues (Animation doesn't load on SonMapEd for whatever reason). So I went to the animation folder, and changed

SonAni_Roll: dc.b $FE, $2E, $2F, $30, $31, $32, $FF, $FF

to

SonAni_Roll: dc.b 0, $2E, $5E $2F, $5F, $30, $60, $31, $61, $32, $FF

The spindash sprites were said to be in $58 to $5D, according to the animation ASM. And I added my half rotated sprites right after that, So I figured that it would be in $5E to $61. /monthly_04_2013/post-2331-0-05216200-1366674417_thumb.png

BUT, when I build and run, I get this as soon as a rolling animation should come up /monthly_04_2013/post-2331-0-16014500-1366674463_thumb.png

Can somebody help fix my problem and maybe even explain it to me so it won't happen again. I am obviously an inexperienced hacker. :/

 

Two things. You forgot a comma between $5E and $2F, and those are 11 parameters, add a ", 0" after the $FF.

 

Wow, I feel dumb. That was way too simple. Thanks though

 

While we're on the topic can someone clear up how the whole thing works? What's the 0 do? And the speed? loop point? o.o

 

The additional 0 is only meant to make sure the next address is even. Not sure it's actually necessary though since it's always transferring bytes, not words.

The animation speed actually doesn't matter, for roll and walk animations it's calculated (and therefore overwritten) in SAnim_WalkRun.

Also, all walking animations and all rolling animations need to have exactly the same number of frames. In order to keep the feet in the same position when the game changes from walking to running animations, the number of the current frame in the animation script ( $1B(an) in s1) is kept, so if the walking animation is on frame 7 and it has to switch to the running animation, the frame of the running animation will be the same (number 7) if the frame should still be displayed, or of course the next one if the frame timer reaches 0. 

Therefore those $FF at the end of the line, if the game needs to read the 8th entry from the beginning of the animation, it has to be either a frame of the animation or the $FF to go back to the first frame.

 

Even though that's byte data, their offsets are indexed as words.

Code:

dc.w SonAni_Walk-SonicAniData
dc.w SonAni_Run-SonicAniData
dc.w SonAni_Roll-SonicAniData
(...)

Therefore the starting addresses have to be even.

 

No, that doesn't actually matter, nineko. These words are not supposed to point to even addresses only, since you're reading data byte by byte. Reading a pointer that points to an odd address is a matter of reading a word that contains an odd number -- nothing that processor can't handle.

These zeros seen in animation data is most likely auto-alignment. I'm pretty sure Yuji Naka enabled an assembler option to automatically align any group of bytes on the even addresses to protect himself from address errors - as you may easily miss something by doing aligning data manually. Animations and a lot of other data that coded straight into assembly therefore have a forced alignment. Even some mappings data: if you look at the original Obj34 mappings (Map_Obj34), they have alignment. However, take a look at Sonic's original sprite mappings - none of data is aligned until the end of file. I'm pretty sure Obj34 mappings were coded manually in the assembly and Sonic's mappings are generated by a special dev tool that Naka wrote back then.

 

I see, thanks for the explanation. I've been living in a lie since the soniNeko days