How to port animations from Sonic 2 Nick Arcade to Sonic 1?

Puto · Dec 22, 2006

I ported Sonic's art, mappings, and dynamic PLCs from Sonic 2 Nick Arcade to Sonic 1. However, if I try a plain copy-paste of the S2NA Animations on Sonic 1, the animations use the wrong sprites. Can anyone please tell me how I can fix this?

Stealth · Dec 22, 2006

If all of the data was replaced correctly, you still need to correct the animation routine to choose the correct sprites for the walking/running animations. The animation data only contains data for the flat surface versions, and part of that routine manipulates those values to get the angled versions. The Sonic 1 routine will create the wrong frame ID values because Sonic 2 uses more walking frames

Puto · Dec 22, 2006

Those aren't the only ones that are broken. Practically every single animation is using the wrong sprites, with things such as wall recoil sprites in the middle of running.

Puto · Dec 22, 2006

Also, apparently, for whatever reason, the game doesn't read any sprite with a value above $80.

Quickman · Dec 22, 2006

General rule of frames: if one is broken somehow, chances are it will break the rest unless you're very clever.

Fix the walking and running animations (it's a simple case of dropping in the code for SAnim_WalkRun in S2NA) and I have a feeling the others will fix themselves.

Puto · Dec 22, 2006

Not without fixing the $80 thing though.

jman2050 · Dec 22, 2006

The $80 thing is simple. At loc_D700 there's an add.b d1,d1 statement. Obviously, the designers didn't intend for any more than 128 mappings for any given sprite, else they would've used add.w like they were supposed to. Change it to that and the $80 problem should go away.

StephenUK · Dec 22, 2006

When I ported the Wai beta sprites to S1 for Megamix, I had to knock the first frame off the mappings set for Sonic. As soon as I did this and fixed the hardcoded animation data, it all worked out fine.

Puto · Dec 22, 2006

jman2050 said:

The $80 thing is simple. At loc_D700 there's an add.b d1,d1 statement. Obviously, the designers didn't intend for any more than 128 mappings for any given sprite, else they would've used add.w like they were supposed to. Change it to that and the $80 problem should go away.
Click to expand...

No, that didn't work.

jman2050 · Dec 22, 2006

Hmm, I said that because that was the fix I used when Cinossu had the same problem. Unless I'm forgetting something else...

EDIT - Ah, excuse me. There was something else. At SAnim_Do2:

Code (Text):

moveq #0,d1

move.b $1B(a0),d1; load current frame number

move.b 1(a1,d1.w),d0; read sprite number from script

bmi.s SAnim_End_FF; if animation is complete, branch

Similar code in S2 looks like this.

Code (Text):

moveq #0,d1

move.b $1B(a0),d1

move.b 1(a1,d1.w),d0

cmpi.b #$F0,d0

bcc.s loc_1B3C4

As yuou can see, in S1, any sprite number above $80 will end the animation. In s2, that number was increased further. I imagine the limit in S3 was increased also.

Puto · Dec 22, 2006

<div class='quotetop'>QUOTE (Quickman @ Dec 22 2006, 08:18 AM)

Puto · Dec 25, 2006

Anybody else has any idea on how to fix the angle problem? (Now I'm trying to port Tails instead, and from S2F, but the general idea remains)

Quickman · Dec 25, 2006

I seem to recall I had the same problem with Sonic's walking/running animations. The problem was I'd ported too much code from SAnim_WalkRun and it was reading too many sprites for the animation.

Puto · Dec 25, 2006

And the fix for that would be...?

Quickman · Dec 25, 2006

Well, considering I wasn't porting anything from Nick Arcade my solution was to put back some of the original code. =P

How to port animations from Sonic 2 Nick Arcade to Sonic 1?

Useful Searches