Basic Questions and Answers Thread

I'm trying to make an alternate hurt routine which, instead of causing the player to drop rings, will check to see if the player has 10 rings or less, and if so kill the player. Otherwise, it should knock the player back and delete 10 rings. However, what it actually does is kill the player no matter what :

Hurt_?????:

        cmpi.b    #$A, ($FFFFFFFE).w    ; is their 10 rings?
        blt.w    Hurt_NoRings        ; if their is less than 10 rings, branch
        sub.w    #$A, ($FFFFFE20).w
        ori.b    #1,($FFFFFE1D).w ; update the ring counter
        move.b    #4,$24(a0)
        bsr.w    Sonic_ResetOnFloor
        bset    #1,$22(a0)
        move.w    #-$400,$12(a0)    ; make Sonic bounce away from the object
        move.w    #-$200,$10(a0)
        btst    #6,$22(a0)
        beq.s    Hurt_Reverse
        move.w    #-$200,$12(a0)
        move.w    #-$100,$10(a0)

 

You should change Obj37_ResetCounter: instead of Hurt routine.

 

Again, at work, so going by knowledge on a headache I might add.  But shouldn't you be comparing a word, not a byte?  Ring_count is a word, so imagine you have 516 rings.  You code will compare with the byte instruction, and it will branch to kill, because 05 is under 10.  05 is at $FFFE and 16 is at $FFFF.

You don't want to change it to $FFFF either because then if you had say 109 rings, when it compare, it will only compare 09, under 10 rings, you die.  So to fix your issue, a simple change from cmpi.b to cmpi.w should do the trick.

 

now when I get injured, it deletes 10 rings every time, resulting in the counter rolling back to a very large glitched amount of rings. It's like the kill check isn't there :

 

You used wrong RAM in the check - $FFFFFFFC to $FFFFFFFF is the "init" checksum, while the ring one is the used by you in the sub.w line.

 

Wow, I can't believe I screwed up such a simple thing! Now the only issue is that the ring counter doesn't update when the number of rings is pushed below 10 (but before the player dies). I can't quite figure out why.

 

Use

Code:

		ori.b	#$80,($FFFFFE1D).w ; update ring counter

instead of the on you have now.

 

What's the difference between the two? I'd like to know for future reference.

 

Two reasons come to mind.

The first is demo game-play, as there are level gimmicks that have the potential to do something randomly that can change the outcome of the character's play. For a demo with fixed controls each and everytime it's ran, you'll want the random number to be fixed each time so that the demo always results in the same demonstration.

The second is down to a request by SEGA themselves in their hardware/software document, it states for an "XBAND" feature (which was initially designed for game-play between two machines, possibly through the phone lines or some shit), which requires the pseudo-random number generator to be fixed initially, called ONLY ONCE in a frame, and only ONE machine generating it and sending it to the other machine. Basically to ensure that both machines have the same random number, seeded the same way, etc, ensuring synchronisation. Those playing via KEGA's "Netplay" feature may notice desyncing at random intervals, and I'm willing to bet that the random number not being handled correctly in this manner, is one of the reasons why.

 

Honestly, when doing this (before getting ninja'd by Painto) I assumed to use ORI because the CollectRing routine used it to add rings to the counter. So, used this to "subtract" 10 from the counter (mind the SVN labels):
 

 


@resetcounter:
sub.w #10,(v_rings).w ; reset number of rings to zero
ori.b #-$0A,(f_ringcount).w ; update ring counter
Oddly enough, it worked without a problem.
 
Also, 


cmpi.w    #$A, ($FFFFFFFE).w    ; is their 10 rings?
         blt.w    Hurt_NoRings        ; if their is less than 10 rings, branch
 
 
If you to make Sonic die with 10 rings or less (and not just less than 10), you might want to use BLE command instead, which Branches if Less than or Equal to:
 

 


HurtSonic:
tst.b (v_shield).w ; does Sonic have a shield?
bne.s @hasshield ; if yes, branch
cmpi.w #$A,(v_rings).w ; <----------------------------- does Sonic have 10 rings?
ble.w @norings ; <--------------------------------------if not, branch
jsr FindFreeObj
bne.s @hasshield
move.b #id_RingLoss,0(a1) ; load bouncing multi rings object
move.w obX(a0),obX(a1)
move.w obY(a0),obY(a1)

@hasshield:
move.b #0,(v_shield).w ; remove shield
move.b #4,obRoutine(a0)
bsr.w Sonic_ResetOnFloor
bset #1,obStatus(a0)
move.w #-$400,obVelY(a0) ; make Sonic bounce away from the object
move.w #-$200,obVelX(a0)
 
However, you may want to consider changing the maximum amount of rings Sonic can physically lose. Otherwise, it would be possible for Sonic to drop 32 rings into the level, and only actually lose 10 internally. To do this find your equivalent ringloss subroutine:
 


RLoss_Count: ; Routine 0

movea.l a0,a1
moveq #0,d5
move.w (v_rings).w,d5 ; check number of rings you have
moveq #32,d0 ;<------------------------------------------------ change to 10
cmp.w d0,d5 ; do you have 32 or more?
bcs.s @belowmax ; if not, branch
move.w d0,d5 ; if yes, set d5 to 32
 
And change the value in the labeled line to 10.

 

I'll keep some of your tips in mind, but I purposefully omitted the ability for sonic to drop rings (the hurt routine being based on Hurt_Shield), and I want it to kill him only if he has less than ten (at ten, sonic would lose ten rings, reducing him to 0 but not finishing him off).

 

When you're subtracting rings, like

        subi.w    #$A, (ring_count).w    ; take 10 rings

This will update the RAM adress.  You have now subtracted 10 rings.  Change this RAM to anything and that's your ring count. 

        move.w    #$5, (ring_count).w    ; 5 rings

You now have 5 rings.  But that's all you have done.  You've updated the Ring Count, but you haven't updated the HUD to display it.

  ori.b #$80,($FFFFFE1D).w ; update ring counter

This command updates the Ring counter's HUD.  You need this command everytime you change the ring_count RAM (unless you don't want the HUD to display it for any reason).

If you do a search for adding/subtracting/clearing/whatever to the Ring_count's RAM, you'll see above or below it the "ori.b" command to update the HUD.  Similar with the timer, score and lives (although it will be "ori"ing or adding or clearing a different RAM address).  Always ori.b #$80 to RAM address $FE1D to update the Ring's HUD.

 Here's an example:

    addq.b #1,(Life_count).w  ; Give an Extra Life

Imagine you had 3 lives.  You come to this command, you now have 4.  Although the HUD will continue to display 3 until it sees and reads:

    addq.b #1,(Update_HUD_lives).w  ; Update Life HUD

Now the HUD will display the correct amount of lives according to the Life_count RAM.  As you can see, this isn't "ori.b"ing, but you get the idea.

Two reasons come to mind.


The first is demo game-play, as there are level gimmicks that have the potential to do something randomly that can change the outcome of the character's play. For a demo with fixed controls each and everytime it's ran, you'll want the random number to be fixed each time so that the demo always results in the same demonstration.


The second is down to a request by SEGA themselves in their hardware/software document, it states for an "XBAND" feature (which was initially designed for game-play between two machines, possibly through the phone lines or some shit), which requires the pseudo-random number generator to be fixed initially, called ONLY ONCE in a frame, and only ONE machine generating it and sending it to the other machine. Basically to ensure that both machines have the same random number, seeded the same way, etc, ensuring synchronisation. Those playing via KEGA's "Netplay" feature may notice desyncing at random intervals, and I'm willing to bet that the random number not being handled correctly in this manner, is one of the reasons why. 




Both make perfectly logical sense.  Thanks for clearing that up.

 

Are their any blank PLCs I could use in Labyrinth zone? I'm adding new object art, but I don't know what value the art should be set to, so I can avoid overwriting things like the level, object, and HUD art.

 

There's a section of VRAM starting at $1C6 with $19 available tiles, and another at $2FA with 5 tiles. That's pretty much all that's available without removing anything.

 

Finally, I got some time for hacking and I started everything from scratch. So which level editor can you recommend to me?

 

Sonlvl is by far my favorite. not only is the interface more intuitive, but it doesn't suffer from a strange error that causes a certain other popular editor to wipe level layouts every time you edit them XD

 

SonLVL is certainly a good choice. It's my preferred method of modifying level layouts just because of how convenient the interface feels compared to SonED2. Mind you, I don't consider SonED2 completely worthless. I actually use it much more often for art editing. I also have yet to encounter this level wiping error some people have mentioned.

 

SonED2 is amazing for art editing, and personally, I find it quite useful with serving its main purpose as a level editor.

As with Shockwave, I have yet to encounter this supposed level wiping error, and mind you, I've been using SonED2 for a year or so now. I'd assume it's the result of Stealth not adding in an autosave feature, hence when someone gets butterfingers and hits the X button or Escape key by mistake, their work isn't saved, and on top of this there isn't a prompt to save your work before closing...so yeah, you more or less have to save your shit manually before closing SonED2 or you have to start over =P

 

Marble zone appears to have 50 duplicate tiles. I do not think anyone has to guess what program I would recommend that will remove them although I note that the way Retro Graphics Toolkit fixes the blocks using the remove duplicate tiles function is to subtract one from all tiles that are grater than the tile and all block tile entries that refer to the removed tile are set the tile that was kept. This causes animations to refer to different tiles.

 

Anyone know how I fix this little bug?



what I have circled in white is suppose to be the points that appear after destroying a badnik.