Making Sonic lose rings per second in Sonic 1 help

We are trying to make a new Super Sonic code but we can't make Sonic lose 1 ring per second while

super. Can anyone help us? We already have code to make Sonic lose Super status once he has no rings if you needed to know that.

 

In your coding using a spare RAM space or something, can you make it start at 60, make it count down every frame, once it reaches 0, set it to 60 again and subtract 1 from ring count? Here's in example. When Sonic turns Super, make a RAM address set to 60 like so:

move.b #$3C,(SpareRAM).w ; Set SpareRAM to 60Then somewhere else in your SuperSonic code that gets read every frame, put something like this:

; ...
subq.b #1,(SpareRAM).w ; Minus 1 from RAM
bne.s + ; If it's not 0, branch
move.b #$3C,(SpareRAM).w ; Set SpareRAM to 60 again
subq.w #1,(Ring_count).w ; Take 1 ring away
ori.b #1,(Update_HUD_rings).w ; Update HUD to show a ring has been taken
+
; ...This is just from the top of my head.

 

Why don't you just port the code from Sonic 2? or am I confusing this with something else?.

 

It's a whole lot easier if you'd just port the code from S2 into S1. Fuck all that complicated noise. Directly porting the ring losing routine is like taking candy from a baby.

Also, who is this we, or are you just doing that in order to fit the Venom persona? Just curious.

 

I've noticed this happening on quite a few other forums as well.

 

Out of curiosity, why do you want to use a new RAM address, when there are frames already available at $FFFFFE22? Sure, by using another RAM address you can have sub-second precision (e.g. you can start counting from 30 frames and keep it precise), but imo it would be just simpler to do something like this, in Hud_ChkTime (Hivebrain disassembly):

Hud_ChkTime:
tst.b ($FFFFFE1E).w ; does the time need updating?
beq.s Hud_ChkLives ; if not, branch
tst.w ($FFFFF63A).w ; is the game paused?
bne.s Hud_ChkLives ; if yes, branch
lea ($FFFFFE22).w,a1
cmpi.l #$93B3B,(a1)+ ; is the time 9.59?
beq.s TimeOver ; if yes, branch
addq.b #1,-(a1)
cmpi.b #60,(a1)
bcs.s Hud_ChkLives
subq.w #1,($FFFFFE20).w ; <-- add this line
move.b #1,($FFFFFE1D).w ; <-- add this line
move.b #0,(a1)
addq.b #1,-(a1)
cmpi.b #60,(a1)
bcs.s loc_1C734
move.b #0,(a1)
addq.b #1,-(a1)
cmpi.b #9,(a1)
bcs.s loc_1C734
move.b #9,(a1)Of course (1) you will need to change the order of the subroutines, and put Hud_ChkTime above Hud_ChkRings, and fix the mutual branches accordingly. But in the end, in this way you can keep it much simpler.
Of course (2) you will need to enclose the two lines above between a cmpi.b (AM I SUPER SONIC) and a beq.b (YEAH DECREASE RINGS) of sorts.

 

Branch commands cannot use a .b or you will get errors. They must be either .s (short branches), .w (word-sized branches), or you can just use something like this:


[...]
bne.s moresupercode
jmp (subtractrings).l
moresupercode:
[...]

(This is basically JEQ in essence)

 

OH MY GOD, people at Sonic Retro made a horrible mistake when they made me a Tech Member, thanks for knowing ASM better than me, I have so much to learn.

Let me just paste a line, a random line, from the soniNeko disasm:

beq.b Use_NekoIndexIt's amazing, I could compile a disasm which contains over 60 bxx.b instructions :O

tl;dr bxx.b == bxx.s, at least in ASM68K.EXE

 

=O

I did not know that. It's probably because I use AS instead of ASM68k, but meh. Depends on whether you're using ASM68K.EXE or AS. Either way.

 

Either way, let me tell you something. The staff often had some private discussions about you in the past months, to decide if we wanted to ban you or not. I've always been in your favour so far, but after your last post you just lost an ally. In case a new discussion arises, I'll be against you.


Tip: when you say that someone is wrong, make sure he's actually wrong.

 

Here's an interesting fact that's related, some people have been known to use .2 for word branches, although it's strange as neither "asm68k" nor "AS" support it.