[Clownacy]

Now, I've seen in S1 hacks, like Metal Sonic Hyperdrive, that when the title card makes the level fade in, the level art and the objects are slightly off-centre, causing the camera to move up or to down to align them once the gameplay begins. It's only for a couple of frames, but damn is it annoying. Porting S1's title card to S2 presents the same problem, only with the default zones. I've never noticed this bug with stock S1, but since I've seen it in hacks with new levels, I believe it's in there too, only it's masked in some way by the level design.

Now, to anyone who is experiencing this, I think I found a fix. More of a messy workaround, but it doesn't seem to work otherwise. I've only tested this with my S2 port, but... well, just give it a go.

For S2 users, under the '+' under Level_TtlCard, comment out the branch to JmpTo_DeformBgLayer.

Then, directly under Level_ClrHUD, add these lines:

	jsr	(ObjectsManager).l
	jsr	(RunObjects).l
	jsr	(BuildSprites).l

Then, at Level_FromCheckpoint, under the branch to SetLevelEndType, add that 'bsr.w JmpTo_DeformBgLayer' you removed earlier.

For S1 users, you should just move the branch to DeformLayers, under Level_SkipTtlCard, to under the branch to OscillateNumInit, under Level_SkipClr. You might also have to copy the three 'jsr's under to Level_LoadObj to there, also.

It's not what I'd call a sound fix, but giving the objects some more time to process, and deforming the background after some other stuff has been done seems to do the trick.

Anyone else have any input on this bug?

[KingofHarts]

I've never noticed this bug AT ALL... though I have noticed with the Sonic 1 title cards, in my hack anyway, that only on certain levels, the title card will hang in its current position before continuing its movement for a few frames. in particular the Act # piece. I'll keep a lookout for it though, absolutely.

*Was hoping to be more productive upon my return... but that's all I've got.*

[Lorenzo]

This bug is more noticeable when you apply this fix Fix Camera Y Position for Tails. Then I took a look at vanilla S2: it's hardly noticeable, but when you are aware of this bug, you can barely see that the camera moves a little when the level has just finished loading.

I applied your changes with the "Camera Y position for Tails" fix and it seems to work just fine.

[KingofHarts]

I'll keep a more careful eye out for it with that in mind... on that note you reminded me what I really need to do... once I get back into hacking again... that likely solves a problem with Tails and the camera that I've been having.

[Clownacy]

So, another strange fix (well, it feels like a workaround): play S3K, enable debug mode on LBZ1, fall to death at the bottom of the level. Notice how, if the camera's close enough, it and Sonic flip out? I've been trying to track the cause down for a while, for my S2 hack, and have had no luck, so I devised another strange workaround.

loc_1C202, it uses Screen_Y_wrap_value, but, unlike many other places where this is used, it doesn't perform a check for if Camera_Min_Y_pos is -$100, which indicates a wrapping level. Like I said, loc_1C202 uses this wrap value regardless of if the level is wrapped or not. Somehow, in the cases of levels that have a height of $800 instead of $1000, this doesn't present a problem.

After the blt.s, add a check for this, as so:

		cmpi.w	#-$100,4(a2)	; does the level wrap vertically?
		bne.s	loc_1C216	; if not, branch

That seems to do it. However, one more thing. Return to life whilst dying from touching the bottom boundary using debug mode, and watch the camera and Sonic, again, be moved. This time, it's DebugMode; it ANDs both Sonic's and the camera's Y-pos. Of course, removing this 'corrects' the bug, but I can't be sure it would be too good for the levels that should wrap. A check similar to the one above may be needed.

This post has been edited by Clownacy: 10 February 2015 - 06:38 PM