Sonic 1 GAME/TIME OVER in FINAL ZONE

Hi


Is there any difference beetween the GAME/TIME OVER screen in all stages and FINAL ZONE?


Firstly I noticed in FINAL ZONE only the word GAME appeared and not OVER when I lost all lives... but now the game crashes completely in that situation... Any idea of what could it be?

 

Try updating the obj39 (or Obj 3A I'll edit if it is the latter.) If anything it probably crashes due to the final level being separate from the rest code wise. Try going for Simon Wai's S2B disam game over object.

 

I really don't know how to proceed to fix this. In the subroutine "GameOver", if I delete this line:


move.b #$39,($FFFFD0C0).w ; load OVER object


the game doesn't crash... but obviously the text OVER doesn't appear...

 

Back-up first before proceeding: Try getting a clean Sonic 1 ASM file and in that file, find Obj39. Copy and replace it in your ASM file. Then you have an unedited GAME OVER object, see if it's okay afterwards.

 

Thanks for reply redhotsonic,


I already tried that and the result is the same, the game crashes in FZ at the GAME or TIME OVER screen... My Obj39 code is untouched so this can't be the problem... I don't know where the problem is and I really need help to try to fix it...

 

The "GAME" and "OVER" objects are always loaded in the same place in memory ( $FFD080 and $FFD0C0 I think). Maybe you created an object in one of those slots, and that object has it own routine counter. if the routine counter is 6 or more when the "game over" happens, the game loads the objects in those slots, but rather than moving 2 to the routine counter to set it properly, it adds 2, so what would happen in this case is a routine counter of 8 or more with only 3 routines for the object, therefore a crash.


It's only a theory of course.

 

Interesting theory, thanks. I have looked and I didn't see any other object created by me using that addresses...


I have tested more and I have seen that when I remove the line:


move.b #$39,($FFFFD0C0).w ; load OVER object


The game doesn't crahs and it loads the GAME TIME OVER objects to the vram. Of course, the OVER object is not showed because I deleted that line, but everything works how it should...


When I keep that line, the game crashes and if I look at the vram I see that GAME TIME OVER is not loaded so the game crashes before it can load the object.... I don't know if this helps someone to see where the problem could be....

 

It makes sense if you consider those informations with what I wrote before. This is from object 39:







Obj39_Index: dc.w Obj39_ChkPLC-Obj39_Index ; << first routine (0)


dc.w loc_C50C-Obj39_Index ; << second routine (2)


dc.w Obj39_Wait-Obj39_Index ; << third routine (4)


; ===========================================================================


Obj39_ChkPLC: ; XREF: Obj39_Index


tst.l ($FFFFF680).w ; are the pattern load cues empty?


beq.s Obj39_Main ; if yes, branch


rts



The first routine for the object checks whether the graphics have been loaded or not, so if the routine counter in $24 is set to 6 or more, the game will skip this routine and won't wait for the graphics to be loaded before it runs the object's code, and since the object's routine counter is wrong, the game crashes.


By the way, I wrote 6 or more, but I think it would crash as well with an odd number.


You should check the ram (more precisely address FFD0E4) with regen in your final zone.


Another way to test this theory would be to clear the byte in FFD0E4 when you create the "over" object. It won't work if FFD0E4 is modified after you clear it, but that's unlikely.

 

OK, thanks, you are completely right. I didn't had Regen at hand so I tried to clear $FFFFD0E4 just before load the OVER object and the GAME OVER screen appear correctly.... How can I see what is doing this to work bad to try to fix it?


I have checked where D0E4 is used and it only appears in the title cards (Level_DelayLoop) and in the continue screen (Cont_ClrObjRam)...

 

Try to find what's in FFD0C0 before you move the object number there, it's the object's ID. That way, you'll know what object is being loaded there.


If FFD0C0 is a 0, maybe you're mistakenly storing data in the object sst, around FFD0E4. It may be happening as well if D0C0 isn't 0 (some data stored there but not an object), but it's unlikely.

That isn't how it works. FFD0E4 is $24(An) when (An) is FFD0C0. ($D0C0+$24).

 

Well, I have checked with Regen and the last object was there before it load the GAME/TIME OVER object was the object 34 (the title cards). You was right about D0E4 too, there is the value 06, that skips the first routine of the object GAME/TIME OVER and crashes the game... so your theory is correct...


What can I do now to fix it?

 

The problem is in your title card object then, the memory it's using isn't cleared. There should be a "bra.w deleteobject" at the end of the object's code.


Here's the original:





Card_ChangeArt: ; XREF: Card_ChkPos2


cmpi.b #4,obRoutine(a0)


bne.s Card_Delete


moveq #plcid_Explode,d0


jsr (AddPLC).l ; load explosion patterns


moveq #0,d0


move.b (v_zone).w,d0


addi.w #plcid_GHZAnimals,d0


jsr (AddPLC).l ; load animal patterns


Card_Delete:


bra.w DeleteObject ; <<--------------------------------------- HERE


; ===========================================================================


Card_ItemData: dc.w $D0 ; y-axis position


dc.b 2, 0 ; routine number, frame number (changes)


dc.w $E4


dc.b 2, 6


dc.w $EA


dc.b 2, 7


dc.w $E0


dc.b 2, $A



If it's still there, there's probably something before it that prevents the program from reaching that line. You probably made some changes, so check those first.

 

I don't see nothing rare there... I added 2 lines but nothing important.... Anyway, if I remove that lines, the bug is still there.... I have checked about D0E4, and its 06, but when it loads the title cards, it changes to 02... after the card goes out of the screen, it backs again to the value 06... I don't see why :S

 

It should be in your obj34_wait routine, it goes from obj34_wait: / Card_Wait: (in the svn disassembly) til bra.w deleteobject. If you can't find the problem, post it here.

 

I still don't see nothing rare comparing it with the original source... I only added that 2 lines there, but the bug was there before that 2 lines was added...




Obj34_Wait: ; XREF: Obj34_Index


tst.w $1E(a0) ; is time remaining zero?


beq.s Obj34_ChkPos2 ; if yes, branch


subq.w #1,$1E(a0) ; subtract 1 from time


bra.w DisplaySprite


; ===========================================================================


Obj34_ChkPos2: ; XREF: Obj34_Wait


tst.b 1(a0)


bpl.s Obj34_ChangeArt


moveq #$20,d1


move.w $32(a0),d0


cmp.w 8(a0),d0 ; has item reached the finish position?


beq.s Obj34_ChangeArt ; if yes, branch


bge.s Obj34_Move2


neg.w d1


Obj34_Move2:


add.w d1,8(a0) ; change item's position


move.w 8(a0),d0


bmi.s locret_C412


cmpi.w #$200,d0 ; has item moved beyond $200 on x-axis?


bcc.s locret_C412 ; if yes, branch


bra.w DisplaySprite


; ===========================================================================


locret_C412:


rts


; ===========================================================================


Obj34_ChangeArt: ; XREF: Obj34_ChkPos2


cmpi.b #4,$24(a0)


bne.s Obj34_Delete


move.b #1,($FFFFFE1E).w ; update time counter


clr.b ($FFFFF7CC).w ; unlock sonic controls


moveq #2,d0


jsr (LoadPLC).l ; load explosion patterns


moveq #0,d0


move.b ($FFFFFE10).w,d0


addi.w #$15,d0


jsr (LoadPLC).l ; load animal patterns


Obj34_Delete:


bra.w DeleteObject

 

Did you change anything in the title card's configuration data (positions)?


Here's the original for reference:





Card_ConData: dc.w 0, $120, $FEFC, $13C, $414, $154, $214, $154 ; GHZ


dc.w 0, $120, $FEF4, $134, $40C, $14C, $20C, $14C ; LZ


dc.w 0, $120, $FEE0, $120, $3F8, $138, $1F8, $138 ; MZ


dc.w 0, $120, $FEFC, $13C, $414, $154, $214, $154 ; SLZ


dc.w 0, $120, $FF04, $144, $41C, $15C, $21C, $15C ; SYZ


dc.w 0, $120, $FF04, $144, $41C, $15C, $21C, $15C ; SBZ


dc.w 0, $120, $FEE4, $124, $3EC, $3EC, $1EC, $12C ; FZ



If we consider the routine number is 6, that's really the routine being run. If it's 6, it should delete the object as soon as it reaches the "changeart" part, but it doesn't, so it probably never gets there. So I see three possibilities:


- the counter never reaches zero (this is unlikely, the new graphics wouldn't load, so you would have noticed it)


- it never removes the "on screen" flag (bit 7 in 1(a0) tst.b 1(a0)+bpl.s blabla), this would be a problem since it really shouldn't happen,


- or it never reaches the finish position (cmp.w 8(a0),d0+bcc.s blabla), therefore the question :/


I hate that title card's code, that's why I made my own >_>

 

Thanks a lot for everything SpirituInsanum. The bug is finally removed and everything works fine now. There was a change in the line of the FZ card due to an option of Vladikcomper's utillity. So problem solved! Thanks!

 

I would like to thank SpirituInsanum too.


Your excellent detailed explanations also helped to find an insidious bug in S1 Hacking Studio 2.0. I was already aware of this one by few users, however I didn't have time to find the issue. Thanks to Phycho FRG I knew that this bug was present in clean S1HS2, thanks to you we both know what caused it.


I'm very impressed with this bug. This is truly one of the most notable bugs I know (along with another epic bug in old S1HS v.1.1, known as "black water", was ridiculously caused by mistake in SonEd2 project files of LZ).


In S1 Hacking Studio 2.0, Card_ConData looks like this:



; ---------------------------------------------------------------------------
; Title card configuration data


; Format:


; 4 bytes per item (SSSS FFFF), where SSSS is start pos and FFFF is end pos


; 4 items per level (GREEN HILL, ZONE, ACT X, oval)


; ---------------------------------------------------------------------------


; Vladikcomper: this data was moved to BIN-files, which are updated by S1HS


Obj34_ConData: incbin "mapbin\ttlcards_cfg_0.bin"


incbin "mapbin\ttlcards_cfg_1.bin"


incbin "mapbin\ttlcards_cfg_2.bin"


incbin "mapbin\ttlcards_cfg_3.bin"


incbin "mapbin\ttlcards_cfg_4.bin"


incbin "mapbin\ttlcards_cfg_5.bin"


incbin "mapbin\ttlcards_cfg_6.bin"



As you see, a data array per every zone is in binary files, the data is updated by S1HS.


S1HS2 is likely to generate wrong start and end positions for the ACT X in final zone. While ACT X isn't displayed, it is still loaded, but stays off-screen, this is how it was in original Sonic 1. I haven't confirmed this though, but I'm sure that due to wrong configuration ACT X starts moving infinitely and occupies the object slot for "OVER" text.


To fix the GAME/TIME OVER bug, you can simply replace:



incbin "mapbin\ttlcards_cfg_6.bin"



with original

Code:

 dc.w 0, $120, $FEE4, $124, $3EC, $3EC, $1EC, $12C ; FZ