Sonic and Sega Retro Message Board: Some changes and fixes for Sonic 2 - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 16 Pages +
  • ◄ First
  • 11
  • 12
  • 13
  • 14
  • 15
  • Last ►
    Locked
    Locked Forum

Some changes and fixes for Sonic 2

#181 User is offline Clownacy 

Posted 05 November 2015 - 10:54 AM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
Okay, there's something seriously wrong with CNZ's background, but I don't know the cause.

For some bizarre reason, DrawInitialBG seems to skip drawing a row of blocks if the level is Casino Night Zone. Without this check, CNZ act 1 will have a row of blank blocks replacing the lowest part of its background. At the same time, with this check, CNZ act 2 has a row of blank blocks at the top of its background! It's more apparent if you port S3K's layout format, like I did, since the blank blocks will be replaced with garbage.

Since I have no idea why a hackish check is needed to make act 1 happy, the best I can offer is a workaround to not make act 2 look silly. Just modify the check in DrawInitialBG to check for act 1 only. 'cmpi.w #casino_night_zone_act_1,(Current_ZoneAndAct).w' should do the job.
This post has been edited by Clownacy: 05 November 2015 - 10:55 AM

#182 User is offline Master Emerald 

Posted 05 November 2015 - 06:33 PM

  • Posts: 3399
  • Joined: 14-December 07
  • Gender:Male
  • Location:Rio de Janeiro - Brazil
  • Project:-
  • Wiki edits:22
Didn't see this mentioned but on Sonic 2 Final the Waterfall splashes on Aquatic Ruin are garbled while they're fine on Sonic 2 Wai Proto (it was fixed on S2 Mobile!) ;p

#183 User is offline Clownacy 

Posted 05 November 2015 - 07:58 PM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
I could have sworn the fix for that was mentioned once in this thread before, but now I can't find it.

Anyway, the Git disasm contains fixes for a few bugs, complete with explanations. You can find them by searching for '1==0' and '1==1'. This includes a fix for the ARZ waterfall, odd sounding notes in the CNZ part of the credits music (I've yet to see a real fix for that), and even scrambled Sonic art on the Sega screen.
This post has been edited by Clownacy: 06 November 2015 - 10:59 AM

#184 User is offline flamewing 

Posted 06 November 2015 - 05:38 AM

  • Emerald Hunter
  • Posts: 1138
  • Joined: 11-October 10
  • Gender:Male
  • Location:🇫🇷 France
  • Project:Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
  • Wiki edits:12
Yeah, the waterfall bug has been found already; SCH has it fixed for years, and I think I mentioned in its thread somewhere (in addition to documenting the fix on Git).

#185 User is offline Clownacy 

Posted 06 November 2015 - 10:27 AM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
SndID_SegaSound is actually played twice on the Sega screen. The only reason you don't hear two SEGA chants one after the other is because the stock PlaySound subroutine can only hold one SFX per frame. This will become a problem, however, if PlaySound is expanded to use a larger queue, such as when you port a different sound driver. Just remove one of the references to SndID_SegaSound, and you'll be all set.

#186 User is offline Master Emerald 

Posted 12 November 2015 - 10:17 PM

  • Posts: 3399
  • Joined: 14-December 07
  • Gender:Male
  • Location:Rio de Janeiro - Brazil
  • Project:-
  • Wiki edits:22
On the same matter of garbled graphics, CPz doors on Sonic 2 Mobile use different mappings that actually look better. I don't know if they are intended to look that way though.

#187 User is offline Clownacy 

Posted 15 December 2015 - 09:22 AM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
Wow, there really is something weird about that graphic (sorry for being a month late, by the way). Look at this:

Posted Image

These are the mappings used by Eggman in DEZ, who hides behind a 'fake' door (it doesn't use the normal door object, and doesn't even actually move, hence the other frames). Because of how its tiles are arranged, it can't display properly. It would need either a more complex set of mappings or an alternate art file.

Now look at this:

Posted Image

Looks familiar, doesn't it? That first one is what CPZ uses, but, looking at the last two, they look way better. Now try spawning a door in CPZ in debug mode.

Posted Image

Uh... yeah. So it is a bug. A door object's sprite frame is determined by the object's subtype. All of CPZ's doors have a subtype of 0, but this is actually HTZ's subtype, according to what debug mode uses. In fact, the real order of the frames in the above image, from left to right, is HTZ, MTZ, CPZ, ARZ. Still doesn't really explain the DEZ door, beside lazy sprite map work, but, whatever. Who knows, the bug's been there since Simon Wai, so maybe whoever made the DEZ Eggman door used a broken CPZ door as reference. *shrugs*
This post has been edited by Clownacy: 30 September 2017 - 09:50 AM

#188 User is offline Clownacy 

Posted 19 December 2015 - 01:45 PM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
Looks like I found a bug in Obj57, the MCZ Boss. When you defeat it, it writes to a random byte of RAM, because of using an uninitialised register. In stock S2, its seems RAM address FFFFED2E get written to, which is part of Ring_Positions. I only noticed the bug because, in my hack, the controls lock and Sonic's DPLCs stop functioning. The code responsible for this is under Obj57_Main_SubA:

	lea	(Boss_AnimationArray).w,a1
	move.b	#$D,7(a1)	; face grin when hit
	_move.b	#2,0(a2)
	move.b	#0,1(a1)	; hover thingies fire off


The only other time this object uses a2 is during object initialisation. What does it hold? Boss_AnimationArray. This looks to be a mistake made while copy/pasting code from Obj57_InitAnimationData. Just change the a2 to a1, and you should be set.
This post has been edited by Clownacy: 19 December 2015 - 06:09 PM

#189 User is offline redhotsonic 

Posted 19 December 2015 - 02:16 PM

  • Also known as RHS
  • Posts: 1583
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic Bash!
  • Wiki edits:24
How do you mean, the controls lock? AS in when Eggman starts blowing up you can no longer move? Making the level impossible to finish? Because it doesn't happen with me. Or am I misunderstanding your post?


EDIT: Oh wait, you mean there was a bug with the GIT disassembly that has caused this? Or...?
This post has been edited by redhotsonic: 19 December 2015 - 02:17 PM

#190 User is offline Clownacy 

Posted 19 December 2015 - 02:46 PM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
I meant that the bug only became noticeable in my hack because of the massive RAM rearrangements. In stock S2, ring RAM gets written to, which is much less noticeable.

#191 User is offline Clownacy 

Posted 09 January 2016 - 08:17 PM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
Cool. Debug mode doesn't reset the 'in air' status(a0) bit, meaning, depending on when you entered debug mode, the camera will have a different deadzone. Try moving up or down after entering debug mode while on the ground. Now do it while jumping. Anyway, in the code for exiting debug mode, Sonic's 'in air' bit is set, so maybe it was intended for that bit to be clear while in debug mode, making the camera stricter. To fix this, just go to Debug_Init, and insert 'bclr #1,(MainCharacter+status).w' after the 'move.b #AniIDSonAni_Walk,anim(a0)'.
This post has been edited by Clownacy: 09 January 2016 - 08:27 PM

#192 User is offline Clownacy 

Posted 14 January 2016 - 07:19 AM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
The pillar objects in ARZ have a bit of a problem setting their width and height. Obj2B sets its width_pixels to define its collision box, and sets it up so the protruding design at the top isn't collidable, while the centre of the pillar is. However, width_pixels is also used to determine when the object is considered off-screen, and not to be displayed. This has the unfortunate effect of the pillar (the top part anyway) vanishing while it's still on-screen, when you're moving left or right. A solution for this would be to hardcode the object's collision box (width_pixels is just supplied as a parameter to SolidObject, and a lot of objects hardcode it anyway), and redefine width_pixels to account for the protruding part of the pillar.

Find Obj2B_Init and change width_pixels from '$10' to '$1C'. Then find Obj2B_Main and replace these instructions:

	moveq	#0,d1
	move.b	width_pixels(a0),d1
	addi.w	#$B,d1


with this:

	moveq	#$10+$B,d1


But that's not all! Use debug mode and move up to off-screen a fully-extended Obj2B pillar. It'll vanish too early, like before.

The fix for this one is a lot simpler. Obj2B is special in that it's really big. Most objects are assumed to be no more than 32 pixels tall, but this one goes beyond that. The object makes the mistake of not signalling that it can surpass this height, by not setting bit 4 of render_flags, which enables an accurate check of the object's height using y_radius, rather than a hardcoded value of 32. Since Obj2B uses y_radius for its collision box, we know it's an accurate way of determining the object's height, so all we have to do is enable this 'accurate height check' flag, and the problem will be solved. Simply go to Obj2B_Init and change the ori.b of render_flags from '4' to '$14'.

And that's Obj2B dealt with... now for Obj82. Unlike before, because you're meant to stand on it, this object's collision is as wide as the top of the pillar, meaning width_pixels is correct, and the object displays correctly. The real problem, however is the same as before: the object is tall, but it doesn't set the 'accurate height check' flag, meaning both the top and the bottom of the pillar vanish early. Like before, change the ori.b of render_flags from '4' to '$14'. But that's not all. There's a slight bit (4 pixels) of the bottom of the pillar that's outside the collision box, meaning it will vanish early. There's no sense in extending the collision box, because that part of the pillar is obviously not meant to be collided with, so we'll have to do some trickery.

My idea is to extend y_radius to account for those 4 extra pixels, but subtract them when y_radius is passed to SolidObject. We want to be careful, though, to not interfere with the object's other subtype (an unused moving platform. Huh). Before the call to SolidObject, insert these instructions:

	tst.b	mapping_frame(a0)	; Is this a pillar?
	beq.s	.notPillar
	subq.w	#2,d3			; If so, shrink the y_radius
.notPillar:


Then go to Obj82_Properties, and change the '$30' to '$30+2'.

Problems like these probably exist in a bunch of other objects, but none of them come to mind. The ARZ pillars have always been especially glaring, to me.
This post has been edited by Clownacy: 14 January 2016 - 08:11 AM

#193 User is offline Clownacy 

Posted 06 February 2016 - 10:16 AM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
This bug's been noticed a bunch, but I've yet to see a fix for it. If you get a Game Over, and enter the Continue screen in HTZ, Tails' art appears corrupt. This is caused by HTZ's transforming cloud art being loaded over Tails' Continue art.

Dynamic_HTZ is responsible for queueing the art to be transferred with QueueDMATransfer, which takes effect around the next frame. The problem here is, the art is queued, you die, get a Game Over, advance to the Continue screen, and then finally the art is loaded. What needs to be done is have the DMA queue reset to a blank slate when we enter the Continue screen. How do we do that? Well, Sonic Team already did half the work for us, since almost every other screen does this:

TwoPlayerResults:
	...

	jsrto	(PlaneMapToVRAM_H40).l, PlaneMapToVRAM_H40

	; Clear DMA queue
	clr.w	(VDP_Command_Buffer).w
	move.l	#VDP_Command_Buffer,(VDP_Command_Buffer_Slot).w

	clr.b	(Level_started_flag).w


ContinueScreen lacks this code, oddly, allowing this bug to manifest. Simply add the code, preferable after the clearRAM macro, and the bug should be fixed.

EDIT: I guess it's about time I ask a question on a bug I don't understand: what the heck is up with HPZ's bridge post art? The top tile is clearly bugged, but that's actually how it is in its art file. Was the file compressed incorrectly, or something? There's no way that ugly thing, that winds up using the cycling waterfall palette, is intentional.
This post has been edited by Clownacy: 06 February 2016 - 03:53 PM

#194 User is offline redhotsonic 

Posted 26 February 2016 - 07:33 PM

  • Also known as RHS
  • Posts: 1583
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic Bash!
  • Wiki edits:24

View PostClownacy, on 06 February 2016 - 10:16 AM, said:

There's no way that ugly thing, that winds up using the cycling waterfall palette, is intentional.



Thought I replied to this a while ago. Oh well. Anyway, isn't it just that the very first 8x8 is just using the wrong palette line? All of the tiles in that object use palette line 3, when the first part is only meant to use palette line 0. I might be wrong though.

#195 User is offline Clownacy 

Posted 10 June 2016 - 06:11 PM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
Ever notice how, during the rumbling as the ARZ boss' pillars rise, the background's scrolling goes screwy? Like, the background shakes, but the scrolling doesn't, so you can see the 'seams' between each scrollable row moving around?

The cause is just what you think it is: the rumble isn't applied to the scrolling, namely Camera_BG_Y_pos. The fix is just as simple: In SwScrl_ARZ, above the 'tst.b (Screen_Shaking_Flag).w', insert a 'moveq #0,d3'. We're going to be using d3 to hold the rumble's Y-offset. Next, after the 'add.w d0,(Camera_Y_pos_copy).w', insert a 'move.w d0,d3'. We can't just add the rumble directly to Camera_BG_Y_pos, like the other values, because Camera_BG_Y_pos isn't 'reset' on each frame: it's constantly in a 'dirty' state, meaning constantly adding the rumble value to it per frame would actually make it scroll instead of shake. Instead, after 'move.w (Camera_BG_Y_pos).w,d1' add an 'add.w d3,d1', and, with that, the bug should be fixed.

  • 16 Pages +
  • ◄ First
  • 11
  • 12
  • 13
  • 14
  • 15
  • Last ►
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users