[Endri]

No problem!

Oh, and just let me conclude my reasoning on the design choice, which I almost forgot:

Aesculapius Piranha, on 05 September 2012 - 05:05 AM, said:

Really I think the monitor thing isn't an issue for the experienced, because what player is going to rack up lives like that if they are experienced enough not to need them? That is a change to prevent n00bs from building cushion.

The first isn't an issue for the experienced either per say. It's more an issue for the niche that goes for score attacks versus everyone else.

Precisely, and that's the point: it becomes an issue if you are designing for example, a hack/game that saves high scores, has leaderboards or scoreboards of any sort. In my case, my game does all the three.

I'll give an {silly} example:

When we were beta testing Doc Egg Fan's Sonic 2 LD, he held a small contest for us, where we would send him our save states from the game, and, he would calculate the scores and give us positions on the "Leaderboards." So, the score at the end of the level, the time you took to beat the level, the amount of rings you had, the amount of lives, if you found or not the emerald in the level, etc, accounted for the final score.

I would destroy every single enemy in the level to inflate my score and grab every ring, to rack up as many lives as possible, and then I would purposefully die. I repeated the process until I was tired of it, then, I would grab the emerald and finish the level as fast as I could with 99 rings.

I'm pretty sure I was the #1 on the Leaderboards a most of the times.

Another {not so silly} example: people do this process (especially the Time Over one) all the time on Taxman's Sonic CD Leaderboards.

[KingofHarts]

Endri, on 08 September 2012 - 11:07 PM, said:

Another {not so silly} example: people do this process (especially the Time Over one) all the time on Taxman's Sonic CD Leaderboards.

My #1 reason for wanting to implement such things. I too would like some kind of record saving implemented into Sonic 1...
But if you wanted to get to the top of those leaderboards so easily, you could just as easily follow my save game editing guide. Cheap plug FTW!

[Endri]

KingofHarts, on 08 September 2012 - 11:18 PM, said:

Endri, on 08 September 2012 - 11:07 PM, said:

Another {not so silly} example: people do this process (especially the Time Over one) all the time on Taxman's Sonic CD Leaderboards.

My #1 reason for wanting to implement such things

The last level in my game is huge ass long, and people will time over frequently, so I had to implement something to keep people from cheating the other people who actually play right.

KingofHarts, on 08 September 2012 - 10:43 PM, said:

That is actually what the Sonic 1 ROM already does. I am opting to instead remove this instruction from level init, and instead clear the ring lives flag at signpost, much like the time over flag instead.

Much thanks Endri!

As I've said earlier, I had Sonic 2 in mind at the time, and Sonic 2 doesn't do it this way.

I'm glad to hear that I was able to shed you some light to the right direction.

[KingofHarts]

So, I have come up with a rather SMALL fix, that is really only notable for nitpickers. Sonic 1's title screen is off-center, and misaligned. I have resolved this, because quite frankly it

FIRST, we will start with the easier part: moving the two title screen objects.
First, go to 0E Title Screen Sonic.asm and go to the second line of TSon_Main: This is Sonic's x position. It should be $F0. Change this to $F8.
Next, open up 0F Press Start and TM.asm and go to PSB_Main: There are 2 lines we will change here. One of them is the PRESS START BUTTON's x position, the other is the TM's x position. Change the first obX from $D0 to $D8. Change the second obX from $170 to $178. Notice that we are moving everything to the right by 8.

Now, for the slightly harder part (for me it was because I'm still learning... but even then it took me only a minute to figure out what I needed to do, so it'll be even easier for you! NO EXCUSES) Now, the rest of the title screen foreground is NOT an object. So... how do we move this over? Easy... we just need to shift the foreground tiles.

Go to sonic.asm and find this tidbit of code, located under Tit_LoadText:

copyTilemap	$FF0000,$C206,$21,$15

See the $C206? Change it to C208! I don't know exactly how it works, but I know that it works, shifting the emblem over 16 pixels... and that's all that matters since everything is centered and looks better.

Like, dislike, suggestions?

[MarkeyJester]

Well since everyone else is in the game, I may as well join in, I have a fix for a bug that you cannot cause very easily in the original Sonic 1 game, but if one were to do something like a special cut-scene involving the screen moving to the right somewhere away from Sonic, and then letting the engine move the screen back to Sonic, then they would probably see this bug in action.

The engine that allows the screen to follow Sonic has the responsibility of ensuring that the screen does not move more than 10 (hex) pixels any direction at one time, this is to allow the draw code to draw the lines of 16x16 blocks correctly without skipping any lines, this means that if Sonic is away from the screen's "central box" position by less than 10 (hex) pixels, then the screen's "central box" will move directly to Sonic, if however, Sonic is further than that, the screen will move at a maximum of 10 (hex) pixels in the direction it is suppose to be moving to. The routine "ScrollVertical:" handles this for moving the screen up and down, "ScrollHoriz:" on the other hand (or should I say "ScrollHoriz2:") handles this for the screen moving right, but not when moving left.

Observe the code for right movement:

loc_65CC:
		cmpi.w	#$10,d0					; <- Restriction
		bcs.s	loc_65D6				; <- Restriction
		move.w	#$10,d0					; <- Restriction

loc_65D6:
		add.w	($FFFFF700).w,d0
		cmp.w	($FFFFF72A).w,d0
		blt.s	loc_65E4
		move.w	($FFFFF72A).w,d0

As you can see by the code marked "Restriction", this is to prevent the screen from moving right by 10 pixels, thereas if we look at the code for left movement:

loc_65F6:
		add.w	($FFFFF700).w,d0
		cmp.w	($FFFFF728).w,d0
		bgt.s	loc_65E4
		move.w	($FFFFF728).w,d0
		bra.s	loc_65E4

The "Restriction" does not exist, the fix is moderately simple:

loc_65F6:
		cmpi.w	#$FFF0,d0				; has the screen moved more than 10 pixels left?
		bcc.s	Left_NoMax				; if not, branch
		move.w	#$FFF0,d0				; set the maximum move distance to 10 pixels left

Left_NoMax:
		add.w	($FFFFF700).w,d0
		cmp.w	($FFFFF728).w,d0
		bgt.s	loc_65E4
		move.w	($FFFFF728).w,d0
		bra.s	loc_65E4

There is another bug related to this which funnily enough is also related to the good old "screen wrapping vertically" bug in Sonic 2 and up, but this is to do with horizontal rather than vertical, at routing "ScrollHoriz2:" we have:

ScrollHoriz2:				; XREF: ScrollHoriz
		move.w	($FFFFD008).w,d0
		sub.w	($FFFFF700).w,d0
		subi.w	#$90,d0
		bcs.s	loc_65F6
		subi.w	#$10,d0
		bcc.s	loc_65CC
		clr.w	($FFFFF73A).w
		rts	

bcc and bcs are unsigned branches, the problem here is that if Sonic is behind the screen (I.e. to the left), the result will be negative (I.e. a value from 8000 to FFFF), but with the unsigned branches it will obviously treat 8000 to FFFF as positive and higher than 7FFF, thus it believes it has to move right rather than left, the fix is also simple, change the unsigned branch conditions with signed branch conditions:

ScrollHoriz2:				; XREF: ScrollHoriz
		move.w	($FFFFD008).w,d0
		sub.w	($FFFFF700).w,d0
		subi.w	#$90,d0
		bmi.s	loc_65F6				; cs to mi (for negative)
		subi.w	#$10,d0
		bpl.s	loc_65CC				; cc to pl (for negative)
		clr.w	($FFFFF73A).w
		rts	

The cc to pl should not matter, but it's best to be safe.

[Kharen]

I've been looking at these types of threads for a while now, and I've got to ask something. Just what exactly do you guys do to discover these kinds of obscure bugs? I mean, I've played through these games a bazillion times, and I've never heard of that last one.

[KingofHarts]

Kharen, on 14 October 2012 - 05:19 AM, said:

I've been looking at these types of threads for a while now, and I've got to ask something. Just what exactly do you guys do to discover these kinds of obscure bugs? I mean, I've played through these games a bazillion times, and I've never heard of that last one.

I've never heard of that last one either, and its well worthy of the SCHG. Nice find Markey.

Anyway, speaking for myself at least and assuming for most others, we play through, but not in the traditional sense of playing through... We also try to look at what exactly everything does, and how the game works... and how it DOESN'T work. How it should work, and how it SHOULDN'T work. You start to just find shit. At the start of this year, I knew absolutely dick about the first thing about a disassembly. Now, while I'm far from good at hacking... I come in with some small level of understanding. and even have a hack, a tool and an engine of my own in the works.

I assume, based on your post... and I apologize if I am mistaken, that you do not hack much. If that is the case, and you want to really get into this... and it's REALLY FUN, I suggest that you do what I did when I started. Grab the latest Sonic 1 disassembly, and start following some of the How To guides, all the while taking the time to try and understand how/why exactly the code works the way it does. Oh, and skim through this thread's history, and the archives... you'll find a gem or two. And ask questions! You can learn a lot from the Tech Members, they are a LOT more experienced with this stuff, and are willing to help, more often than not.

Last but not least, take some time to fuck with random shit and see the result. I did that and found this little trick that I will show you now. This can be applied for anyone applying a Time Attack mode. Go to HUD_Update and find this bit of code:

	@chktime:
		tst.b	(f_timecount).w	; does the time	need updating?
		beq.w	@chklives	; if not, branch (.s -> .w) Mercury Centisecond HUD
		; Remove this for a Time Attack mode... OR just remove the pause function. - KingofHarts mod
                tst.w	(f_pause).w	; is the game paused? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
		bne.w	@chklives	; if yes, branch (.s -> .w) Mercury Centisecond HUD <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
		; Mod end
		lea	(v_time).w,a1

Remove the two lines I noted. What this will do is make the time keep running, even when the game is paused. Now, you will only want this to happen when your Time Attack mode is active, so one thing you could do is implement a flag for Time Attack mode, and add a check for the Time Attack mode flag, and follow it with a bne.s branch to skip the lines I told you to delete. So if you are NOT in Time Attack, Time will stop as normal, otherwise, pausing will not save Time Attack players from a running clock.

And to add to it, I'll re-post something I left on SSRG regarding a fix to a SMALL aesthetic bug I found with the Game Over object that caused it to flicker when the words conjoined. Go to _incObj/39 Game Over.asm and go to this block of code and add the branch to DisplaySprite.

; ===========================================================================
Over_SetWait:
		move.w	#720,anim_frame_duration(a0) ; set time delay to 12 seconds
		addq.b	#2,routine(a0)
		bra.w	DisplaySprite ; KoH additional line to prevent blinking.
; ===========================================================================

This post has been edited by KingofHarts: 14 October 2012 - 09:10 AM

[MarkeyJester]

I donno, I believe the bugs are mainly found by those who are making hacks themselves, because they make changes to the game, some of the bugs that were unnoticed in the original game tend to show up more, and hence, they go to check more carefully in the original game just in case it isn't a bug of their own, and because they know what they're looking for, they find it. I've been working on an in-game level editor, and the camera does not follow Sonic when in editor mode, and when coming out of editor mode, the camera withdrawals itself back to Sonic, thus, I found the bug...

[Cinossu]

Aha, I remember having that left horizontal scrolling bug in S1EE; I could've sworn jman put the solution up on SCHG too once he found it, but eh. Nicely done, Markey.

[Tets]

MarkeyJester, on 14 October 2012 - 09:31 AM, said:

I donno, I believe the bugs are mainly found by those who are making hacks themselves, because they make changes to the game, some of the bugs that were unnoticed in the original game tend to show up more, and hence, they go to check more carefully in the original game just in case it isn't a bug of their own, and because they know what they're looking for, they find it. I've been working on an in-game level editor, and the camera does not follow Sonic when in editor mode, and when coming out of editor mode, the camera withdrawals itself back to Sonic, thus, I found the bug...

That's pretty much it. I discovered one of the Super Sonic transformation bugs in Sonic 2 (the one where the transformation palcycle only works properly the first time around because the RAM value isn't zeroed properly) a few years ago because I was playing around adding new features, double-jump transformation and the like. I might have even posted a quick fix for it here on the forums, though I don't remember very clearly. It's one of the easiest bug fixes in any Sonic game ever, but I still felt like a damn genius when I figured it out.

[KingofHarts]

I still remember my first fix. I made it so that the objects don't freeze when you die, much similar to Sonic CD 2011. Really easy fix, though I DID need help with the second part, as some objects still stopped moving due to the oscillatory routines stopping when Sonic dies.

I tend to find things a little differently, just seeing stuff in code as I comb through, and just screwing about figuring out what it all does... Then again, I also didn't have any real hack outside of Revision C going on... though I have started one now.

[KingofHarts]

Got a question regarding the Large Spikeball Object from SYZ (Object $58)

Let's compare the codes of subtypes horizontal and vertical... there is a difference that is slightly strange to me. One of these two is doing something it doesn't need to be doing...
HORIZONTAL
<asm>

@type01: ; XREF: @index
move.w #$60,d1
moveq #0,d0
move.b (v_oscillate+$E).w,d0 ; load osc value $E
btst #0,status(a0) ; is object flipped?
beq.s @noflip1 ; if not, branch
neg.w d0 ; inverse the osc value
add.w d1,d0 ; add $60 to osc value
@noflip1:
move.w bball_origX(a0),d1
sub.w d0,d1 ; subtract d0 from original x position
move.w d1,x_pos(a0) ; move object horizontally
rts
</asm>

VERTICAL
<asm>

@type02: ; XREF: @index
move.w #$60,d1 ; <- WTF??? Why is this here? It's not even used
moveq #0,d0
move.b (v_oscillate+$E).w,d0 ; load osc value $E
btst #0,status(a0) ; is object flipped?
beq.s @noflip2 ; if not, branch
neg.w d0 ; inverse the osc value
addi.w #$80,d0 ; add $80 to osc value <-HEY why is this not $60?
@noflip2:
move.w bball_origY(a0),d1
sub.w d0,d1 ; subtract d0 from original y position
move.w d1,y_pos(a0) ; move object vertically
rts
</asm>

Anyone want to clear up the difference with me? Why not move the flipped vertical spikeballs in SYZ up slightly, and making the vertical moving code work identically to the horizontal moving code...?
I will try this tonight and report back. I'm not sure why they made this so different, especially since that $60 in d1 is not even used in the vertical moving object... and using $80 requires one to move a flipped vertical spikeball slightly lower... but that is simply nitpicking.

[redhotsonic]

I don't know much about Sonic 1, but from the code you've posted, it looks like d1 is not being used (as $60 anyway). Sometimes, when they create the game, they just leave mistakes in there. Either because they were in a rush, or they changed the code a bit and forgot to take something out.

I remember in Sonic 2's CNZ boss, there's a useless branch, it went something like this:

loc_31B46:
	bra.w	+
+	addq.w	#1,($FFFFF75C).w
	move.w	($FFFFF75C).w,d0
	andi.w	#$3F,d0

I took the branch out, no point in it. Sometimes, you'll find things like this. Everyone makes mistakes.



Also, the "move.w #$60,d1" can be changed to "moveq #$60,d1" and by looking at it, it shouldn't mess it up. moveq is faster. Although, if it acts up, just put it back to move.w. Now that's being nit-picky =P

[KingofHarts]

Well I'm thinking of changing the vertical moving object's code to $60 instead of $80, and if you look at the vertical moving object code, it just adds the immediate value to the osc. value, instead of loading it into d1 first... I'm going to just do the same to the horizontal moving object's code... THAT should be even faster, anyway, right? then you don't even need to take the extra step to load anything into d1... which all in all, seems awfully pointless.

(Though now I gotta move the vertical mirrored spikeballs up a tad... oh well. That's fine. Looks better on SonLVL this way, anyway)

This post has been edited by KingofHarts: 22 October 2012 - 07:20 PM

[MarkeyJester]

Adding/subtracting an immediate word value takes 8 cycles. e.g.:

		addi.w	#$0060,d0

		addi.w	#$0080,d0

Moving a word/quick value to a register first takes 4 cycles, while adding/subtracting the register to another takes a further 4 cycles, totalling 8 cycles. e.g.:

		moveq	#$60,d1
		add.w	d1,d0

		moveq	#$FFFFFF80,d1
		sub.w	d1,d0

No processing time is saved in this instance, if however, you intend to use the same value more than once in a similar fashion, then it would be recommended to use the register storage method.