Basic Questions & Answers thread

I think this section of the bubble code, after Sonic gets the bubble could be useful to look at about the immunity issues:

Code (ASM):

1.     clr.w   $10(a1)
2.         clr.w   $12(a1)
3.         clr.w   $14(a1)
4.         move.b  #$15,$1C(a1)
5.         move.w  #$23,$3E(a1)
6.         move.b  #0,$3C(a1)
7.         bclr    #5,$22(a1)
8.         bclr    #4,$22(a1)
9.  

 

<!--quoteo(post=242900:date=Nov 8 2008, 09:00 PM:name=Tweaker)--><div class='quotetop'>QUOTE (Tweaker @ Nov 8 2008, 09:00 PM)

Now, if you are in Obj2E and you need to call another subroutine, and you know that said subroutine has an rts at its end (playsound and playsound special have it), you can use a jmp, which will use the rts in playsound to return back to the routine that called Obj2E, saving time and some stack:


Of course this is only useful if the playsound routine is the last thing you need to do in your monitor code; if you had other instructions after it, you had to use jsr instead. On the other hand, by using this trick, you can avoid the execution of other code in Obj2E that isn't related to your monitor at all. For example, you have to store a song number in d0 to call the playsound routine, but d0 is also used to contain the monitor subtype in the Obj2E code. So if you call playsound with a jsr, and the execution goes back to the Obj2E code, you're likely to branch wrong if you use the new d0 assuming it's still the monitor subtype.

So yeah, in this particular case both techniques were acceptable, but in some cases, they're not.

[/asm lesson]

 

Yeah, nineko pretty much has it right. In other terms if you put a bsr or jsr in the code it will come back and execute any code after, if you put a jmp, bra or any conditionals it won't come back.

What I would suggest you do is set a blank RAM variable (such as $FFFFC604 in sonic 1) and then test before the bubble code effects sonic if this variable is set, and if it is to branch to a rts as opposed to affecting the amount of air sonic has. So that would be something like:
(in the monitor code)

Code (ASM):

1. move.w #1,($FFFFC604).w

(in the bubble code, Obj64_Wobble)

Code (ASM):

1.                                 beq.s   Obj64_Display   ; if not, branch
2.                                 tst.w         ($FFFFC604).w
3.                                 bne.s        Obj64_NoEffect          ; if not equal to 0, branch
4.                                 bsr.w   ResumeMusic ; cancel countdown music
5. Obj64_NoEffect:
6.                                  rts

Then you're going to have to apply that concept to the section of code where sonic gets out of water finally find a place to clear the RAM when the act is complete (clr.w ($FFFFC604)).

 

He can also put a label in the bubble code and call it directly, duh, I didn't think about that :p

edit: given that he knows where to put the label, and he knows how to branch to such a distant location. Since this is too hard for a beginner, let's proceed with the proposed method instead.

 

Ok, I have decided to keep the goggles monitor as a one use air top-up. I have changed the box art from Goggles to Bubbles.

Anyway there are two problems I found by playtesting the game:

1. When I now collect an air bubble, the music in LZ returns to LZ music and the music in SBZ3 returns to SBZ music, I have changed the zone music to:
My LZ has SBZ music and SBZ has Final Zone Music.

2. When I collect the Goggles box when I am running out of air, Sonic's air supply is supplied as normal but the music remains on the "Countdown" music then goes quiet, until I obtain an air bubble in a bubble source.

Any Ideas? Thanks

(Look in above posts for the code I am using, if neccessary)

 

You might want to check misc/muslist1.bin & muslist2.bin if that helps.

 

I tried to look at these, but I didn't know how. Could you tell me please?

 

You use a Hex Editor, like Hex Workshop or HXD.
In muslist1.bin, you'll get this:

Code (Text):

1. 81 82 83 84 85 86 8D 00

These refer to the music. So, if you change 81 to 8C, you'll get the Boss Music in Green Hill Zone.
The same for muslist2.bin:

Code (Text):

1. 81 82 83 84 85 86

This is when you get out of invincibility, this probably applies to when the countdown is stopped. Just change any number to another song to change it.
Hopefully that clears up stuff for you.

 

Sorry no it doesn't.
The strange thing is that when Sonic finishes his invincibility, the correct music does come up, which I can see in the code in muslist2.bin. It only happens when Sonic recovers oxygen when he is running out of oxygen, and the strange glitch when Sonic gets the Goggles Box when he is running out of oxygen. thanks

 

You could have a look at ResumeMusic, that might help solve some issues.

 

Great! Thanks SOTI it works correctly now.

Now only the monitor problem to sort out...

 

I've been working on a Sonic 1 hack from Hivebrain's 2005 disassembly and I'm having a problem getting Sonic to load his underwater pallet, after adding Amy as a second character.

I setup a clean hacking enviroment for testing this first, and used only 2 guides:

SCHG_How-to:Add_Extra_Characters
and
Making the second character load different palette (Found at Retrohack.org)

And this was the result:

The bottom right part of the picture clearly shows the problem

I searched through the SCHG and the How to section of the wiki, I also looked trrough every page of this topic, and used the forum search tool looking for a topic/answer but could not find one.
If anyone can be of some assistance, I'd be most appreciative.

 

Can someone help me out? How do I work Sonic Tweaker? Whenever I try to load up a rom, they won't show up.

 

If you're using a split disassembly using Sonic Tweaker won't work

 

Can someone explain me the format of the enigma compressed mappings? I can't remember that

 

This question is about a hex editor I'm using. You can analyze the checksum of a selected hex block with it. When I click custom crc check, <a href="http://img49.imageshack.us/my.php?image=crcuh4.png[/IMG]this comes up.</a> What do I fill in for the parameters so it does the checksum the way Sega Genesis games do it (ex: 50 + 6A=BA)?

 

You could have a look at the Enigma compression article on the wiki.

 

This is the very definition of a basic question.

Within reason (Namely the physical limit to the ROM size when compiled), is there any limit to the amount of animation frames Sonic can have? I presume not, because it's uncompressed art streamed directly from the ROM, but I have a little doubt about that.

I ask because I intend to create a better-animated Sonic sprite.

 

The mapping frame is stored in an unsigned byte, so you're limited to 256 frames in the mappings.

EDIT: Actually, in Sonic's animation script, $FD, $FE and $FF have special meanings, so the actual max frame number is 253, and I believe you'd have to modify Sonic's animation routine to allow it to work properly with that number of frames.