Sonic and Sega Retro Message Board: UPDATED: Speed up the ring loss process (even further) with underwater - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

UPDATED: Speed up the ring loss process (even further) with underwater redhotsonic and SpirituInsanum presents...

#1 User is offline redhotsonic 

Posted 30 April 2012 - 12:23 PM

  • Also known as RHS
  • Posts: 1097
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
To further improve the speed of the scattered rings object, read this post! This is separate to the guide within this post.




Warning: This guide is for Sonic 2, and I am using the Xenowhirl 2007 disassembly. For Sonic 1 and/or other disassemblies, it shouldn't be too hard still if you follow this guide. ALSO, REMEMBER TO BACK-UP BEFORE MAKING ANY CHANGES. I'm not held responsible for any screw-ups to your hack.

Also: If you want your scattered rings to act if they're underwater like Sonic does, it is best to follow this guide first (by me).

If you want to use the tables I've supplied in this guide, again, you WILL need to follow this guide first


I bought you the underwater scattered rings guide and SpirituInsanum told us how to speed up the ring loss process. Together, we bring you "How to speed up the ring loss process with underwater".

loc_120BA:
	_move.b	#$37,0(a1) ; load obj37
	addq.b	#2,routine(a1)
	move.b	#8,y_radius(a1)
	move.b	#8,x_radius(a1)
	move.w	x_pos(a0),x_pos(a1)
	move.w	y_pos(a0),y_pos(a1)
	move.l	#Obj25_MapUnc_12382,mappings(a1)
	move.w	#$26BC,art_tile(a1)
	bsr.w	Adjust2PArtPointer2
	move.b	#$84,render_flags(a1)
	move.b	#3,priority(a1)
	move.b	#$47,collision_flags(a1)
	move.b	#8,width_pixels(a1)
	move.b	#-1,(Ring_spill_anim_counter).w
	tst.w	d4
	bmi.s	loc_12132
	move.w	d4,d0
	bsr.w	JmpTo4_CalcSine
	move.w	d4,d2
	lsr.w	#8,d2
	asl.w	d2,d0
	asl.w	d2,d1
	move.w	d0,d2
	move.w	d1,d3
	addi.b	#$10,d4
	bcc.s	loc_12132
	subi.w	#$80,d4
	bcc.s	loc_12132
	move.w	#$288,d4

loc_12132:

	move.w	d2,x_vel(a1)
	move.w	d3,y_vel(a1)
	neg.w	d2
	neg.w	d4
	dbf	d5,loc_120B2



This is part of the scattered rings code. This code repeats itself a maximum of 32 times; each time for each ring (and like said, it will make you scatter a max of 32 rings, but still set your counter to 0). What this code does, is works out how high and how far to scatter a ring, then then whether to make it fly left or right. Once it's done that, it does it again for another ring, and then another, and then another until it either reaches your ring count, or 32. Whilst it's doing this, nothing else can be done. It's not much of a problem when there's not much about, but if you lose a lot of rings when there's so many other objects about and/or in water, it can go slow for a second.



Anyway, This is quite big and slow, and I'm about to show you how to reduce it significantly; speeding the ring loss process, freeing the processor for other work. Instead of doing lots of calculations on the fly over and over, we will use a pre-made table to insert how high, how far and which way we want our rings to go. This will be a lot quicker as we already have the calculations done this way.


But how do we come up with our table? Well, I'm about to show you. But first, in this guide, I will be using two pre-made tables myself. These are for a max of 20 rings above water, and 8 rings below water. Also, the ring spill underwater will be using the effect from my other guide. If you're happy to do the same as me, skip ahead to step 4 (although you might want to read the first couple of steps so you know what's going on).





Step 1 - Change the max amount of rings to spill

In the scattered rings object, go to "loc_120A2:" and the first line you should see is this:

	moveq	#$20,d0


This is hexadecimal for 32, this is the max number of rings it will spill. Take the $ sign out (so it's not hexadecimal anymore), and then change the number to the amount of rings you want it to spill at maximum. If you want it to lose a max of 44 rings for example, then simply change the 20 to 44. If you want to change the number of max rings spill for when underwater (as things get slower underwater) we can add a check to see if underwater and if so, to change the number. Say you want to lose 20 rings over water but only 8 when in the water, you would do this:

loc_120A2:
	moveq	#20,d0			; lose a max of 20 rings
	lea	(MainCharacter).w,a2	; a2=character
	btst	#6,status(a2)		; is Sonic underwater?
	beq.s	+			; if not, branch
	moveq	#8,d0			; lose a max of 8 rings when underwater
+
	cmp.w	d0,d5
	bcs.s	loc_120AA
	move.w	d0,d5


Make sure the Maincharacter is loaded to a2, otherwise it may interrupt with the rest of our work or the original code.

You DON'T have to change the max for underwater, but it is advisable, because things get very slow underwater. The more rings there are, the slower things will get, because more processing power goes in to making them bounce and etc. That's purely the only reason.





Step 2 - Make our tables for pre-calculated figures

go to "loc_120AA:" and change this:

loc_120AA:
	subq.w	#1,d5
	move.w	#$288,d4
	bra.s	loc_120BA


to this:

loc_120AA:
	subq.w	#1,d5
	move.w	#$288,d4
	lea ($FFFFAA00).l,a4	; Load $FFFFAA00 to a4
	bra.s	loc_120BA


$FFFFAA00 is nemesis's decompression buffer's RAM. It's not used during gameplay, so we can use this. All we've done is copied the RAM address to a4.


Then go to "loc_12132:" and change this:

loc_12132:
	move.w	d2,x_vel(a1)
	move.w	d3,y_vel(a1)
	neg.w	d2
	neg.w	d4
	dbf	d5,loc_120B2


to this:

loc_12132:
	move.w	d2,x_vel(a1)
	move.w	d3,y_vel(a1)
	neg.w	d2
	neg.w	d4
	move.w	d2,(a4)+	; Move d2 to a4 then increment a4 by a word
	move.w	d3,(a4)+	; Move d3 to a4 then increment a4 by a word
	dbf	d5,loc_120B2


Just added two lines here. Basically, once one ring has calculated it's x_vel and y_vel when it's going to spill out, it's copied it's values to a4, then a4 has incremented so that the next value can be added. The code repeats itself for the next ring and again, once it's got it's calculations, it's then copied to a4, and keeps doing this for all rings spilled.





Step 3 - Build and test. Let's get our new table!

Save, build and test. Should be no errors. Now, using your emulator (I reccomend Regen), go to the RAM viewer (Tools > RAM viewer) and go to $FFFFAA00. Load any level up. During level loading, the numbers at this RAM address will go crazy, but once the title cards have gone away, it should stop and not do anything (there will still be numbers there).

Now, collect the max number of rings (or more) and then get hurt and lose your rings. They'll scatter everywhere as usual, but all it's values has just been moved to $FFFFAA00. Ta-dah! There's our new table! What you need to do now is open notepad and write your new values in using words. Give it a label too! Here is a guide on how to do it (mine is a max of 20 rings):

; ===========================================================================
; ---------------------------------------------------------------------------
; Ring Spawn Array
; ---------------------------------------------------------------------------

SpillRingData:  dc.w    $00C4,$FC14, $FF3C,$FC14, $0238,$FCB0, $FDC8,$FCB0 ; 4
                dc.w    $0350,$FDC8, $FCB0,$FDC8, $03EC,$FF3C, $FC14,$FF3C ; 8
                dc.w    $03EC,$00C4, $FC14,$00C4, $0350,$0238, $FCB0,$0238 ; 12
                dc.w    $0238,$0350, $FDC8,$0350, $00C4,$03EC, $FF3C,$03EC ; 16
                dc.w    $0062,$FE0A, $FF9E,$FE0A, $011C,$FE58, $FEE4,$FE58 ; 20
                even
; ===========================================================================


It goes x_vel, y_vel, x_vel, y_vel, x_vel, y_vel, x_vel, y_vel, etc, etc.


REMEMBER, if you're doing less rings for underwater, you need to get the max number of rings again, go underwater then get hurt. You'll get another new table. For my underwater, the max is 8. And again, I'm using the underwater scattered rings guide. Here's a guide for 8 rings.

; ===========================================================================
; ---------------------------------------------------------------------------
; Ring Spawn Array Underwater
; ---------------------------------------------------------------------------

SpillRingDataU: dc.w    $0064,$FE08, $FF9C,$FE08, $011C,$FE58, $FEE4,$FE58 ; 4
                dc.w    $01A8,$FEE4, $FE58,$FEE4, $01F8,$FF9C, $FE08,$FF9C ; 8
                even
; ===========================================================================
; ===========================================================================


Notice I've changed the label for the underwater table. I've just stuck a U after it. You will need to insert these (or your own, whatever) into your ASM file. A good place to put it, find "BranchTo5_DeleteObject" and stick it after

BranchTo5_DeleteObject 
	bra.w	DeleteObject






Step 4 - Loading our new tables

Now we've got our new tables, let's use them.

Go back to "loc_120A2:". This is where we will make it load our new tables. The tables will load into a3. Change it to make it look like this:

loc_120A2:
	lea	SpillRingData,a3	; load the address of the array in a3
	moveq	#20,d0			; lose a max of 20 rings
	lea	(MainCharacter).w,a2	; a2=character
	btst	#6,status(a2)		; is Sonic underwater?
	beq.s	+			; if not, branch
	lea    SpillRingDataU,a3	; load the UNDERWATER address of the array in a3
	moveq	#8,d0			; lose a max of 8 rings underwater
+
	cmp.w	d0,d5
	bcs.s	loc_120AA
	move.w	d0,d5


Basically, it will load the overwater table and make 20 the max rings. It then checks if your underwater and if so, load the underwater table and change the max to 8. If not underwater, it will skip doing that bit and carry on with normal. REMEMBER to change the label and max rings to whatever you gave it. It only does this once every time you lose rings, it doesn't repeat itself unlike the calculations below it.


Go to "loc_120AA:" and change this:

loc_120AA:
	subq.w	#1,d5
	move.w	#$288,d4
	lea ($FFFFAA00).l,a4	; Load $FFFFAA00 to a4
	bra.s	loc_120BA


to this:

loc_120AA:
	subq.w	#1,d5
	bra.s	loc_120BA


The Nemesis RAM bit isn't needed anymore; that was just for creating our tables. The "move.w #$288,d4" isn't needed anymore either as that's part of the calculations of spilling the rings.





Step 5 - Using the data from our new tables

Go to "loc_120BA:"

loc_120BA:
	_move.b	#$37,0(a1) ; load obj37
	addq.b	#2,routine(a1)
	move.b	#8,y_radius(a1)
	move.b	#8,x_radius(a1)
	move.w	x_pos(a0),x_pos(a1)
	move.w	y_pos(a0),y_pos(a1)
	move.l	#Obj25_MapUnc_12382,mappings(a1)
	move.w	#$26BC,art_tile(a1)
	bsr.w	Adjust2PArtPointer2
	move.b	#$84,render_flags(a1)
	move.b	#3,priority(a1)
	move.b	#$47,collision_flags(a1)
	move.b	#8,width_pixels(a1)
	move.b	#-1,(Ring_spill_anim_counter).w
	tst.w	d4		; DELETE ME
	bmi.s	loc_12132	; DELETE ME
	move.w	d4,d0		; DELETE ME
	bsr.w	JmpTo4_CalcSine	; DELETE ME
	move.w	d4,d2		; DELETE ME
	lsr.w	#8,d2		; DELETE ME
	asl.w	d2,d0		; DELETE ME
	asl.w	d2,d1		; DELETE ME
	move.w	d0,d2		; DELETE ME
	move.w	d1,d3		; DELETE ME
	addi.b	#$10,d4		; DELETE ME
	bcc.s	loc_12132	; DELETE ME
	subi.w	#$80,d4		; DELETE ME
	bcc.s	loc_12132	; DELETE ME
	move.w	#$288,d4	; DELETE ME

loc_12132:			; DELETE ME
	move.w	d2,x_vel(a1)	; DELETE ME
	move.w	d3,y_vel(a1)	; DELETE ME
	neg.w	d2		; DELETE ME
	neg.w	d4		; DELETE ME
	move.w	d2,(a4)+	; DELETE ME	; Move d2 to a4 then increment a4 by a word
	move.w	d3,(a4)+	; DELETE ME	; Move d3 to a4 then increment a4 by a word
	dbf	d5,loc_120B2


See where it says "DELETE ME"? Do what it says. These are not needed anymore! This is what slows the ring loss down! This calculates the ring loss speeds and etc. Instead, we using our tables. Now, where you just deleted that table, insert this instead:

	move.w	(a3)+,x_vel(a1)		; move the data contained in the array to the x velocity and increment the address in a3
	move.w	(a3)+,y_vel(a1)		; move the data contained in the array to the y velocity and increment the address in a3


So, you have something looking like this:

loc_120BA:
	_move.b	#$37,0(a1) ; load obj37
	addq.b	#2,routine(a1)
	move.b	#8,y_radius(a1)
	move.b	#8,x_radius(a1)
	move.w	x_pos(a0),x_pos(a1)
	move.w	y_pos(a0),y_pos(a1)
	move.l	#Obj25_MapUnc_12382,mappings(a1)
	move.w	#$26BC,art_tile(a1)
	bsr.w	Adjust2PArtPointer2	; This is only needed for two player
	move.b	#$84,render_flags(a1)
	move.b	#3,priority(a1)
	move.b	#$47,collision_flags(a1)
	move.b	#8,width_pixels(a1)
	move.b	#-1,(Ring_spill_anim_counter).w
	move.w	(a3)+,x_vel(a1)		; move the data contained in the array to the x velocity and increment the address in a3
	move.w	(a3)+,y_vel(a1)		; move the data contained in the array to the y velocity and increment the address in a3
	dbf	d5,loc_120B2


ALL DONE! Phew! Let me explain though. What it does now, is load a word from a3 (the table) and inserts it into x_vel, and then increment a3 by a word. Then it loads a word from a3 again (which has been incremented, so it won't be the same word) and inserts it into y_vel, then increment a3 again. Now one ring has it's speeds. It now knows how high to jump, how far to jump and which way to go, a hell of a lot quicker then doing all them calculations!

If you have used my tables I've supplied, then when out of water, you can only lose a max of 20 rings, and when in water, you can only lose a max of 8 rings, and it will act if like they're in water.


The ring loss process will now be much faster! And if in water, it shouldn't slow down (as much)


Any questions/comments/etc, reply!

Enjoy!


Credits

SpirituInsanum - For the idea and speed loss patterns guide (SSRG only). Also for helping me come up with this guide.
Me - For underwater scattered rings.



EDIT: Here is a ROM of Sonic 2 with this guide and my underwater guide combined.
This post has been edited by redhotsonic: 05 May 2012 - 06:51 AM

#2 User is offline Aerosol 

Posted 30 April 2012 - 12:31 PM

  • FML and FU2
  • Posts: 6961
  • Joined: 27-April 08
  • Gender:Male
  • Location:Not where I want to be.
  • Project:Sonic (?): Coming summer of 2055...?
Fascinating. What if you kept the max for above and below water at 32? Would you still see much of a benefit?

#3 User is offline redhotsonic 

Posted 30 April 2012 - 01:13 PM

  • Also known as RHS
  • Posts: 1097
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
Underwater, you'd probably wouldn't. This only speeds up the process on creating the rings. To animate them and to keep them moving and to make them bounce hasn't changed. When you enter the water, a lot more sprites appear (bubbles) and the huge code for checking when to drown, when to make that ding in the water, where to spawn the bubbles, etc etc, is running. When you lose a lot of rings, each one of them rings have to check when to bounce, where to move, blah blah blah. The less rings there are, the more power can go into the underwater coding.


When not in water, you can make it spill more rings, because the underwater coding is not running.


EDIT: Example: If you got to "Obj0A:" and insert a command to delete the object immediately:

Obj0A:
	bra.w	Deleteobject
	moveq	#0,d0
	move.b	routine(a0),d0
	move.w	Obj0A_States(pc,d0.w),d1
	jmp	Obj0A_States(pc,d1.w)
;	blah, blah, blah


Underwater will go miles faster, but the small bubbles will never appear and Sonic will never drown =P
This post has been edited by redhotsonic: 30 April 2012 - 01:20 PM

#4 User is offline SoullessSentinel 

Posted 30 April 2012 - 02:48 PM

  • Posts: 236
  • Joined: 01-October 05
  • Gender:Male
  • Location:Grimsby, England
  • Project:Sonic 1 32X Remix
Good work. Anything that reduces the amount of lag is a plus in my book, it creates a much smoother experience. Nothing is worse than the illusion of speed being broken by a sudden slowdown.

#5 User is offline redhotsonic 

Posted 01 May 2012 - 06:10 AM

  • Also known as RHS
  • Posts: 1097
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
Thanks. The scattered rings is the biggest cause of slowdowns in all Sonic games and hacks =P

#6 User is offline redhotsonic 

Posted 05 May 2012 - 05:49 AM

  • Also known as RHS
  • Posts: 1097
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
Double post, but I found out another way you can speed up the ring loss process even more (if anyone cares). I just ported the S3K priority manager into my hack, and you can make the scattered rings object do something extremely similar. Okay, so this is only making one object do it, but because the amount of rings you can lose, this actually makes a BIG difference (as usual, especially underwater).




Go to "loc_120BA:" (part of the scattered rings object) and delete this line:

	move.b	#3,priority(a1)



When the rings are being created, it won't have to move 3 to it's priority anymore, saving a command per ring created and slightly speeding it up (you'll probably won't notice any difference, but this isn't what I am trying to accomplish here).


Now you're probably thinking "WTF are you thinking you crazy boy? The rings aren't going to be displayed now!" Well, in a way, you're wrong. It will still be displayed, but with a priority of 0. Now, we do not want that, we still want it to be 3, and we're about to fix it, and this will be what speeds it up dramatically.




Go to "loc_121B8" and you should see a command:

	bra.w	DisplaySprite



We are going to replace this with a new code, similar to how S3K does it. In S2, before it can display the sprite, it convert's the object's priority into a word, and then displays it. It does calculations that are about 3 lines long to convert it into a word. When lots of objects use this code every single frame (Sonic and Tails constantly for example), it can be a slow process.


Now, imagine you just got hurt and lost 32 rings, each one of them 32 rings branches to DisplaySprite, does the calculations, then displays the sprite; every single frame! All 32 of them! This slows it down quite a bit! Now, you can't just turn the scattered ring's priority into a word, otherwise it will over-write the scattered rings's "width_pixel". So, what do we do? Well, we can just copy part of the DisplaySprite's coding and insert it into the scattered rings' object coding.


Now, normally, after the rings have jumped to DisplaySprite to convert it's priority into a word, it becomes $180. Look at this:

Priority = 3 (byte)

DisplaySprite:
	lea	(Sprite_Table_Input).w,a1
	move.w	priority(a0),d0			; To be deleted
	lsr.w	#1,d0				; To be deleted
	andi.w	#$380,d0			; To be deleted
	adda.w	d0,a1				; To be changed
	cmpi.w	#$7E,(a1)
	bcc.s	return_16510
	addq.w	#2,(a1)
	adda.w	(a1),a1
	move.w	a0,(a1)

return_16510:
	rts


Now, Priority = $180 (word)


So, we're going to copy this code, then edit it a bit, then move it to the scattered rings object. So copy it, then move it to where the branch was in the scattered rings object. So you have something looking like this:


WAS:

loc_121B8:

	tst.b	(Ring_spill_anim_counter).w
	beq.s	BranchTo5_DeleteObject
	move.w	(Camera_Max_Y_pos_now).w,d0
	addi.w	#$E0,d0
	cmp.w	y_pos(a0),d0
	bcs.s	BranchTo5_DeleteObject
	bra.w	DisplaySprite



And change that to this:

loc_121B8:

	tst.b	(Ring_spill_anim_counter).w
	beq.s	BranchTo5_DeleteObject
	move.w	(Camera_Max_Y_pos_now).w,d0
	addi.w	#$E0,d0
	cmp.w	y_pos(a0),d0
	bcs.s	BranchTo5_DeleteObject
	lea	(Sprite_Table_Input).w,a1
	move.w	priority(a0),d0			; To be deleted
	lsr.w	#1,d0				; To be deleted
	andi.w	#$380,d0			; To be deleted
	adda.w	d0,a1				; To be changed
	cmpi.w	#$7E,(a1)
	bcc.s	+
	addq.w	#2,(a1)
	adda.w	(a1),a1
	move.w	a0,(a1)
+
	rts



"To be changed" means that line is going to be edited and the "To be deleted", well, guess what we will do with that? =P




Change

	adda.w	d0,a1				; To be changed



To this:

	adda.w	#$180,a1



As we now know 3 would equal $180, we can just add $180 straight to a1. No more calculations every single frame, we've already done it!




You should have something like this now:

loc_121B8:

	tst.b	(Ring_spill_anim_counter).w
	beq.s	BranchTo5_DeleteObject
	move.w	(Camera_Max_Y_pos_now).w,d0
	addi.w	#$E0,d0
	cmp.w	y_pos(a0),d0
	bcs.s	BranchTo5_DeleteObject
	lea	(Sprite_Table_Input).w,a1
	adda.w	#$180,a1
	cmpi.w	#$7E,(a1)
	bcc.s	+
	addq.w	#2,(a1)
	adda.w	(a1),a1
	move.w	a0,(a1)
+
	rts



So, what have we done? Well, we saved a line of it branching somewhere for a start, it's already there, so that's a plus! Also, we're moving $180 straight to a1, rather than doing them 3 lines of calculations! What a time saver! ALL done. That was easy, eh? Now your scattered rings will be even quicker, hopefully not slowing down anything!


Enjoy.








EDIT

This is optional, you do not have to do this if you do not like

If you look below the code you just edited:

Obj_37_sub_4:
	addq.b	#2,routine(a0)
	move.b	#0,collision_flags(a0)
	move.b	#1,priority(a0)
	bsr.w	sub_11FC2

Obj_37_sub_6:
	lea	(byte_1237A).l,a1
	bsr.w	AnimateSprite
	bra.w	DisplaySprite
; ===========================================================================

BranchTo5_DeleteObject 
	bra.w	DeleteObject




You can see a command move 1 to priority, and displaying it again. This is for when you collect the rings (when the rings turn into them sparkly effects). You can do something extremely similar here if you like. It will make quite a bit of a difference if you collect a lot of scattered rings at the same time, otherwise, it won't do too much. If you want it to do the same, then you can. But it won't be $180 again! When 1 has been through DisplaySprite's calculations, it will equal $80 instead!


So, at "Obj_37_sub_4:", delete this line/command:

	move.b	#1,priority(a0)



Then, at "Obj_37_sub_6:", replace:

	bra.w	DisplaySprite



with this:

	lea	(Sprite_Table_Input).w,a1
	adda.w	#$80,a1
	cmpi.w	#$7E,(a1)
	bcc.s	+
	addq.w	#2,(a1)
	adda.w	(a1),a1
	move.w	a0,(a1)
+
	rts




So you have something like this:

Obj_37_sub_4:
	addq.b	#2,routine(a0)
	move.b	#0,collision_flags(a0)
	bsr.w	sub_11FC2

Obj_37_sub_6:
	lea	(byte_1237A).l,a1
	bsr.w	AnimateSprite
	lea	(Sprite_Table_Input).w,a1
	adda.w	#$80,a1
	cmpi.w	#$7E,(a1)
	bcc.s	+
	addq.w	#2,(a1)
	adda.w	(a1),a1
	move.w	a0,(a1)
+
	rts




Done, you've made it slightly faster again!


As usual, here is a S2 ROM with this guide applied. It also has this guide and this guide applied.



Cheers,
redhotsonic






EDIT at 15:41 GMT: EDIT: I realised I accidently left a branch in the guide which I have fixed in the guide.

Accidently, I put this:
loc_121B8:

	tst.b	(Ring_spill_anim_counter).w
	beq.s	BranchTo5_DeleteObject
	move.w	(Camera_Max_Y_pos_now).w,d0
	addi.w	#$E0,d0
	cmp.w	y_pos(a0),d0
	bcs.s	BranchTo5_DeleteObject
	bra.w	DisplaySprite			; I accidently left this here
	lea	(Sprite_Table_Input).w,a1
	adda.w	#$180,a1
	cmpi.w	#$7E,(a1)
	bcc.s	+
	addq.w	#2,(a1)
	adda.w	(a1),a1
	move.w	a0,(a1)
+
	rts



SO MAKE SURE YOUR ASM FILE ACTUALLY SAYS THIS:

loc_121B8:

	tst.b	(Ring_spill_anim_counter).w
	beq.s	BranchTo5_DeleteObject
	move.w	(Camera_Max_Y_pos_now).w,d0
	addi.w	#$E0,d0
	cmp.w	y_pos(a0),d0
	bcs.s	BranchTo5_DeleteObject
	lea	(Sprite_Table_Input).w,a1
	adda.w	#$180,a1
	cmpi.w	#$7E,(a1)
	bcc.s	+
	addq.w	#2,(a1)
	adda.w	(a1),a1
	move.w	a0,(a1)
+
	rts

This post has been edited by redhotsonic: 05 May 2012 - 09:42 AM

#7 User is offline KingofHarts 

Posted 05 May 2012 - 10:39 AM

  • Amigo
  • Posts: 1373
  • Joined: 07-August 10
  • Gender:Male
  • Location:CHICAGO, IL
  • Project:Finding a job, Sonic Triad Studio, Sonic 1 REV C
  • Wiki edits:1
Lemme know when this is 100% and I'll cook up another wiki page.

#8 User is offline redhotsonic 

Posted 05 May 2012 - 05:50 PM

  • Also known as RHS
  • Posts: 1097
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
It is 100% =P

#9 User is offline Aerosol 

Posted 06 May 2012 - 12:43 AM

  • FML and FU2
  • Posts: 6961
  • Joined: 27-April 08
  • Gender:Male
  • Location:Not where I want to be.
  • Project:Sonic (?): Coming summer of 2055...?
You sure you won't find another way to speed up ring loss?

#10 User is offline KingofHarts 

Posted 06 May 2012 - 03:27 AM

  • Amigo
  • Posts: 1373
  • Joined: 07-August 10
  • Gender:Male
  • Location:CHICAGO, IL
  • Project:Finding a job, Sonic Triad Studio, Sonic 1 REV C
  • Wiki edits:1

View PostAerosolSP, on 06 May 2012 - 12:43 AM, said:

You sure you won't find another way to speed up ring loss?


If he does, I'll just amend the wiki. No prob.

EDIT: Here you go. NOW WHY THE HELL IS MY WIKI EDITS COUNT STILL AT 1??? This is at least the third guide I've put on the wiki... not to mention the other edits I've done throughout the wiki...
This post has been edited by KingofHarts: 06 May 2012 - 05:23 AM

#11 User is offline redhotsonic 

Posted 06 May 2012 - 04:44 PM

  • Also known as RHS
  • Posts: 1097
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24

View PostAerosolSP, on 06 May 2012 - 12:43 AM, said:

You sure you won't find another way to speed up ring loss?


There is one more, but it's hardly worth it. You wouldn't notice any difference.




View PostKingofHarts, on 06 May 2012 - 03:27 AM, said:

EDIT: Here you go. NOW WHY THE HELL IS MY WIKI EDITS COUNT STILL AT 1??? This is at least the third guide I've put on the wiki... not to mention the other edits I've done throughout the wiki...


Cheers, mate. Yeah, it says you've only made 1. Maybe you should PM a member of the site staff to get it resolved.

#12 User is offline qiuu 

Posted 06 May 2012 - 05:16 PM

  • Posts: 134
  • Joined: 05-February 08
  • Gender:Not Telling
  • Project:Blue Ball & Blocks
  • Wiki edits:13
Just a little note on these two lines:

        lea     (Sprite_Table_Input).w,a1
        adda.w  #$180,a1


As Sprite_Table_Input is just a constant value (namely the address $FFFFAC00), you can do this calculation during compile-time rather than run-time by writing

        lea     (Sprite_Table_Input+$180).w,a1

or just
        lea     Sprite_Table_Input+$180,a1


instead of the two lines above. Sprite_Table_Input+$180 is the same as $FFFFAC00+$180 which is the same as $FFFFAD80 (writing either would work).
It won't make a notable difference performance-wise, but it doesn't hurt to know I guess, and might make the code a tiny bit nicer to read.

(btw, the ().w just tells the compiler to address it as a word sized value, which works because $FFFFAC00 interpreted as signed value is -$5400 which is in the range [-8000,$7FFF]. Leaving it out works just as well, and if the compiler does some optimization, it will even produce the same bytecode taking the same amount of CPU cycles to run.)

#13 User is offline redhotsonic 

Posted 06 May 2012 - 05:34 PM

  • Also known as RHS
  • Posts: 1097
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24

View Postredhotsonic, on 06 May 2012 - 04:44 PM, said:

View PostAerosolSP, on 06 May 2012 - 12:43 AM, said:

You sure you won't find another way to speed up ring loss?


There is one more, but it's hardly worth it. You wouldn't notice any difference.





View Postqiuu, on 06 May 2012 - 05:16 PM, said:

Just a little note on these two lines:

        lea     (Sprite_Table_Input).w,a1
        adda.w  #$180,a1


As Sprite_Table_Input is just a constant value (namely the address $FFFFAC00), you can do this calculation during compile-time rather than run-time by writing

        lea     (Sprite_Table_Input+$180).w,a1

or just
        lea     Sprite_Table_Input+$180,a1


instead of the two lines above. Sprite_Table_Input+$180 is the same as $FFFFAC00+$180 which is the same as $FFFFAD80 (writing either would work).
It won't make a notable difference performance-wise, but it doesn't hurt to know I guess, and might make the code a tiny bit nicer to read.



That's one of them. The reason why I didn't put it in the guide before is because when I tried it before, it froze. So I put in the guide the other way. But then I realised the reason why it froze was because I forgot to put the $ sign in it lol

#14 User is offline KingofHarts 

Posted 06 May 2012 - 09:39 PM

  • Amigo
  • Posts: 1373
  • Joined: 07-August 10
  • Gender:Male
  • Location:CHICAGO, IL
  • Project:Finding a job, Sonic Triad Studio, Sonic 1 REV C
  • Wiki edits:1

View Postqiuu, on 06 May 2012 - 05:16 PM, said:

Just a little note on these two lines:

        lea 	(Sprite_Table_Input).w,a1 		adda.w  #$180,a1


As Sprite_Table_Input is just a constant value (namely the address $FFFFAC00), you can do this calculation during compile-time rather than run-time by writing

        lea 	(Sprite_Table_Input+$180).w,a1

or just
        lea 	Sprite_Table_Input+$180,a1


instead of the two lines above. Sprite_Table_Input+$180 is the same as $FFFFAC00+$180 which is the same as $FFFFAD80 (writing either would work).
It won't make a notable difference performance-wise, but it doesn't hurt to know I guess, and might make the code a tiny bit nicer to read.

(btw, the ().w just tells the compiler to address it as a word sized value, which works because $FFFFAC00 interpreted as signed value is -$5400 which is in the range [-8000,$7FFF]. Leaving it out works just as well, and if the compiler does some optimization, it will even produce the same bytecode taking the same amount of CPU cycles to run.)


I'll add this to the page now. I believe this is in part 2...
BTW RHS, look on the wiki at Part 2.5... I copied and pasted from the topic to the wiki so I'm positive this isn't a typo on my end.

Is it me, or did you make a mistake typing this:
     	
lea 	(Sprite_Table_Input).w,a1
adda.w  #$80,a1
cmpi.w  #$7E,(a1)


Instead of this:
lea 	(Sprite_Table_Input).w,a1
adda.w  #$180,a1
cmpi.w  #$7E,(a1)



I wasn't sure but it looks like a typo to me... I'll wait before changing anything, just lemme know. BTW this post editor is a bastard... I've had to edit the asm portion of my post 8 times now...
This post has been edited by KingofHarts: 06 May 2012 - 09:44 PM

#15 User is offline KingofHarts 

Posted 06 May 2012 - 09:59 PM

  • Amigo
  • Posts: 1373
  • Joined: 07-August 10
  • Gender:Male
  • Location:CHICAGO, IL
  • Project:Finding a job, Sonic Triad Studio, Sonic 1 REV C
  • Wiki edits:1
I'm double posting cuz I don't wanna deal with reediting my previous post another 8 times... sorry.

I fixed up part 2 of the guide. Can someone please make sure I got the edit in Part 2 correct? Thanks. :D

  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users