Sonic and Sega Retro Message Board: Basic Questions & Answers thread - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 354 Pages +
  • ◄ First
  • 352
  • 353
  • 354
    Locked
    Locked Forum

Basic Questions & Answers thread NEWBIES: Start here!

#5296 User is offline E-122-Psi 

Posted 17 November 2014 - 11:11 AM

  • Posts: 1430
  • Joined: 29-December 09
  • Gender:Male
  • Wiki edits:41
Does anyone know if there's a way to specify branches that ask if an object is touched in Sonic 1? I need a command that can tell when it is being touched specifically by Sonic's object.

The case is specifically for the bumper in SYZ, if an object connected to Sonic touches it, he still bounces.

#5297 User is offline Hitaxas 

Posted 17 November 2014 - 07:26 PM

  • SEGA: Sorry Classic Sonic, we are sending you back to 1994
  • Posts: 1420
  • Joined: 30-September 07
  • Gender:Male
  • Location:Back in Litchfield,CT
  • Project:Sonic: Super Deformed (head director) - Slowly working on it.
  • Wiki edits:196
I'm not too sure about checking for anything specific touching an object, but you could run a code that will search object ram and check for Sonic/player character, and branch accordingly:

CharCheck:
	        lea	(Object_RAM+$400).w,a1  ; check obj ram   
	        moveq	#$6F,d6                 ; search to end of table
	        tst.w	(Two_player_mode).w     ; 2p mode check
	        beq	CharCheck_Loop       ; branch if equal
	        moveq	#$27,d6	                ; search to $BF00 exclusive

CharCheck_Loop:
	        tst.b	(a1)	                ; is there an object in this slot?
	        beq	CharCheck_NextObj	; if not, check next object
	        cmp.b	#$01,(a1)	        ; is the object Sonic?
	        bne     NoCollide                       ; if it isn, Do not do anything!
                bra     CharCheck_NextObj       ; Branch to check for the next object in objRAM

CharCheck_NextObj:
	        lea	next_object(a1),a1      ; load obj address ; goto next object RAM slot
	        dbf	d6,CharCheck_Loop	; repeat until end
	        
NoCollide:
                rts	        


This might be able to help you, unless the object that is connected to Sonic is run through his object rather than separate.
This post has been edited by Hitaxas: 17 November 2014 - 07:30 PM

#5298 User is offline FraGag 

Posted 17 November 2014 - 09:42 PM

  • Posts: 656
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6

View PostArtmeierCompanies, on 16 November 2014 - 09:22 PM, said:

When I tried porting the Hyper Sonic stars into Sonic 2, it works fine (what I mean by that is that it loads and doesn't crash the game), but there's a problem. Whenever the object is loaded, it fucks up the palette.

Posted Image

The line that makes this happen is:

add.w	(MainCharacter+y_pos).w,d3

I know that because when I change it, the palette stays normal. What on earth is going on? I ripped the code straight from S3K (with some adjustments of course).


Maybe the sprite mappings for the stars are corrupted/invalid? If you changed that line, the stars might not be visible, because they would be off screen, and therefore the sprite mappings wouldn't be used (can you confirm that the stars didn't show up when you touched that line?). The normal level palette is located right after the sprite table, so if the sprite table overflows (because there are too many sprites, which can be caused by broken mappings), sprite data will be written to the palette.

#5299 User is offline ArtmeierCompanies 

Posted 18 November 2014 - 03:55 PM

  • (AKA TheRoboticDeveloper)
  • Posts: 26
  • Joined: 16-April 13
  • Gender:Male
  • Location:Nice try
  • Project:Sonic: Video Games Dimension
For now, I'm using the S2 Super Sonic stars, so the mappings are in S2 format. Whenever I do change/remove the line, the stars do display, but they're at the top of the screen.

#5300 User is offline Hitaxas 

Posted 18 November 2014 - 08:56 PM

  • SEGA: Sorry Classic Sonic, we are sending you back to 1994
  • Posts: 1420
  • Joined: 30-September 07
  • Gender:Male
  • Location:Back in Litchfield,CT
  • Project:Sonic: Super Deformed (head director) - Slowly working on it.
  • Wiki edits:196
So you need to move them down to Sonic's Y_pos? why not try something like this:
move.w	y_pos(a1),y_pos(a0)

Assuming that Sonic is object a0 and the stars are a1, this should work out.

#5301 User is offline FraGag 

Posted 18 November 2014 - 10:24 PM

  • Posts: 656
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6

View PostArtmeierCompanies, on 18 November 2014 - 03:55 PM, said:

For now, I'm using the S2 Super Sonic stars, so the mappings are in S2 format. Whenever I do change/remove the line, the stars do display, but they're at the top of the screen.

OK. Now, does frame 6 exist in the mappings?

		move.b	#6,mapping_frame(a0)



When I first read the code, I thought it was always overwritten, but I read the code again and now I see that the frame is indeed used when the object appears initially. If the mappings have less than 6 frames (which is the case with the original obj7E mappings), frame 6 will be garbage. By moving the object offscreen initially, the bug is avoided; since frame 6 is only used once, when the object initially appears, it doesn't occur when you scroll the camera to make the object visible after it's been loaded for a while.

#5302 User is offline ArtmeierCompanies 

Posted Yesterday, 05:43 PM

  • (AKA TheRoboticDeveloper)
  • Posts: 26
  • Joined: 16-April 13
  • Gender:Male
  • Location:Nice try
  • Project:Sonic: Video Games Dimension
Alright, I found the problem and is fixed. Apparently, it WAS an issue with the sprite table and the palettes. All I had to do is move the palette line RAM addresses away from the sprite table RAM and I just extended the sprite table.

#5303 User is offline FraGag 

Posted Yesterday, 10:32 PM

  • Posts: 656
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6

View PostArtmeierCompanies, on Yesterday, 05:43 PM, said:

Alright, I found the problem and is fixed. Apparently, it WAS an issue with the sprite table and the palettes. All I had to do is move the palette line RAM addresses away from the sprite table RAM and I just extended the sprite table.

Now you just have more garbage in your sprite table. The size of the sprite table is more than enough for the Genesis's limit of 80 sprites on screen. BuildSprites just doesn't check for overflow. It's not normal that you would need to enlarge the sprite table.

#5304 User is offline ArtmeierCompanies 

Posted Today, 07:01 AM

  • (AKA TheRoboticDeveloper)
  • Posts: 26
  • Joined: 16-April 13
  • Gender:Male
  • Location:Nice try
  • Project:Sonic: Video Games Dimension
Alright, since the invincibility stars and the hyper stars aren't going to appear at the same time, so I had the hyper stars and invincibility stars use uncompressed art and DPLCs, and use the same VRAM location, so now I no longer need to extend the sprite table. When I reset the sprite table back to normal size and put the palette RAM addresses where they originally were, it worked just fine.
This post has been edited by ArtmeierCompanies: Today, 07:02 AM

#5305 User is offline KingofHarts 

Posted Today, 07:46 AM

  • Amigo
  • Posts: 1403
  • Joined: 07-August 10
  • Gender:Male
  • Location:CHICAGO, IL
  • Project:Finding a job, Sonic Triad Studio, Sonic 1 REV C
  • Wiki edits:1
Yea... golden rule, and I follow it with my Sonic 1 hack... anything shield or star related... just have it in the same location. For example, in my hack, I've got invincibility stars, 4 shields, bonus stage entry effect, and super stars ALL in the exact same place. Try to find other instances where you can do that. IIRC the skid dust, spindash dust and splash art do the same thing in their location.

#5306 User is offline Hitaxas 

Posted Today, 02:09 PM

  • SEGA: Sorry Classic Sonic, we are sending you back to 1994
  • Posts: 1420
  • Joined: 30-September 07
  • Gender:Male
  • Location:Back in Litchfield,CT
  • Project:Sonic: Super Deformed (head director) - Slowly working on it.
  • Wiki edits:196
I'm curious and want a technical explanation for this.

In Sonic 3, there is a code that resets player position data.

Reset_Player_Position_Array:
		cmpa.w	#Player_1,a0			; is object player 1?
		bne.s	Reset_Player_Position_ArrayP2	; if not, branc
; Reset_Player_Position_ArrayP1:
		lea	(Pos_table).w,a1
		lea	(Stat_table).w,a2
		move.w	#$3F,d0
; loc_10DEC:
-		move.w	x_pos(a0),(a1)+			; write location to pos_table
		move.w	y_pos(a0),(a1)+
		move.l	#0,(a2)+
		dbf	d0,-

		move.w	#0,(Pos_table_index).w
; loc_10E04:
Reset_Player_Position_ArrayP2:
		tst.w	(Competition_mode).w	; are we in Competition mode?
		beq.s	locret_10E24		; if not, branch
		lea	(Stat_table).w,a1
		move.w	#$3F,d0
; loc_10E12:
-		move.w	x_pos(a0),(a1)+
		move.w	y_pos(a0),(a1)+
		dbf	d0,-
		move.w	#0,(Pos_table_index_P2).w

locret_10E24:
		rts
; End of function Reset_Player_Position_Array


Now this is self explainable. But It got me thinking, how is something like this handled in Sonic 2?

Well, I looked in S3 for codes that called for Reset_Player_Position_Array, and then searched S2 for similar code. Here's where I found that S3K calls for it during character init codes.
Looking at how S2 does it, I noticed the routine is much smaller.

	move.w	#$3F,d2
-	bsr.w	Sonic_RecordPos
	subq.w	#4,a1
	move.l	#0,(a1)
	dbf	d2,-


In my test, this pretty much does the same thing as Reset_Player_Position_Array...

Is the code S3K uses faster in any way? Or would using the second code be a better way to go?
This post has been edited by Hitaxas: Today, 02:14 PM

#5307 User is offline MainMemory 

Posted Today, 02:52 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 3206
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
The code used in S3K is definitely faster than the code used in S2 when you factor in the contents of the Sonic_RecordPos function:
Sonic_RecordPos:
	move.w	(Sonic_Pos_Record_Index).w,d0
	lea	(Sonic_Pos_Record_Buf).w,a1
	lea	(a1,d0.w),a1
	move.w	x_pos(a0),(a1)+
	move.w	y_pos(a0),(a1)+
	addq.b	#4,(Sonic_Pos_Record_Index+1).w

	lea	(Sonic_Stat_Record_Buf).w,a1
	lea	(a1,d0.w),a1
	move.w	(Ctrl_1_Logical).w,(a1)+
	move.w	status(a0),(a1)+

	rts
; End of subroutine Sonic_RecordPos

Sonic 2's code ends up repeatedly writing the index variable, then reading it, using it to get an offset into the tables, writing the position values, writing the status value, then moving back one element in the status table and overwriting what it just wrote with 0.
This post has been edited by MainMemory: Today, 02:52 PM

#5308 User is offline Hitaxas 

Posted Today, 03:08 PM

  • SEGA: Sorry Classic Sonic, we are sending you back to 1994
  • Posts: 1420
  • Joined: 30-September 07
  • Gender:Male
  • Location:Back in Litchfield,CT
  • Project:Sonic: Super Deformed (head director) - Slowly working on it.
  • Wiki edits:196
Thank you for the explanation. :)

  • 354 Pages +
  • ◄ First
  • 352
  • 353
  • 354
    Locked
    Locked Forum

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