Basic Questions and Answers Thread

If you're not dealing with tails, you could always just overwrite that orange with the old yellow.

 

I want Tails in my hack, I just haven't added him yet. Also, I want to make use of the multiple shades of yellows to make the hud look better.

 

A single sprite of object 21's mappings:

dc.b $80, $D, $80, 0, 0This is a single sprite. The format is; YY, 0S, VV, VV, XX.
YY = Y sprite position (relative to object)

S = Shape

VVVV = Pattern index

XX = X sprite position (relative to object)

The pattern index VVVV is what you are after. Funny it should be mentioned actually, Dandaman described the binary format on the previous page recently, where VVVV in bits is PCCF HAAA AAAA AAAA:

You'll find that most of the sprites to the HUD have the first byte of VV either 80 or A0 (i.e. 1000 0000 or 1010 0000), this is to decide upon the individual palette lines, so that for using the yellow, the first line is used, for flashing red, the second line is used. To make the sprite pieces use the next line, simply change all of the sprites VV from 80 to A0. But watch out, the flashing red may be a problem, unless you use line 1 of Sonic's red for the flash, in which case you'd be pretty much swapping 80 with A0 and A0 with 80. Mind you, an alternative would be to remove the sprites that use A0, and change all 80 to A0, this would cause the flashing to blink invisible instead of red (just an idea).

 

Thank you Markey. I didn't know that the HUD was an object. I'll do it when I get to my laptop.

 

I'm having trouble getting an object I'm making to display any art at all. I've examined Markeys post on the previous page, but I still can't get it to display anything. Below is the display code in the object:


move.l #Obj56_MapUnc_2FAF8,mappings(a0)
move.w #$7400/$20,art_tile(a0)
bsr.w DisplaySprite

and the plrlist:


;---------------------------------------------------------------------------------------
; PATTERN LOAD REQUEST LIST
; Hill Top Zone primary
;---------------------------------------------------------------------------------------
PlrList_Htz1: plrlistheader
plreq $73C0, ArtNem_Buzzer_Fireball
plreq $7400, ArtNem_Eggpod
;plreq $7640, ArtNem_HtzRock
plreq $78C0, ArtNem_HtzSeeSaw
plreq $7BC0, ArtNem_Sol
plreq $6FC0, ArtNem_Rexon
plreq $A400, ArtNem_Spiker
plreq $8680, ArtNem_Spikes
plreq $8780, ArtNem_DignlSprng
plreq $8B80, ArtNem_VrtclSprng
plreq $8E00, ArtNem_HrzntlSprng
PlrList_Htz1_End
;---------------------------------------------------------------------------------------
; PATTERN LOAD REQUEST LIST
; Hill Top Zone secondary
;---------------------------------------------------------------------------------------
PlrList_Htz2: plrlistheader
plreq $7CC0, ArtNem_HtzZipline
plreq $82C0, ArtNem_HtzFireball
plreq $84C0, ArtNem_HtzValveBarrier
PlrList_Htz2_End

The goal is to get the eggmans ship (in particular the EHZ variant, which has a specific mappings and art location) to appear. It's loaded the art in the exact same place that the original mappings used, but it still displays nothing. I highly doubt that it has to do with the art getting overwritten, as in that case it would still display something, and I could easily work around it. The code used for calling the art and mappings was taken directly from the EHZ boss object, and fits markey's tutorial, so I have trouble believeing that's the issue. Did I call displaysprite incorrectly? Or is it something I can't see?

 

Is there anything below thr branch?

 

Below is the entirety of the objects code. Due to my experimental Copy/paste tactics, it might be a little redundant, but it does exactly what I want it too, bar the display issue (the routine counter used on most objects isn't there, I don't feel it requires it atm)

Code:

Obj4c:
	move.l	#Obj56_MapUnc_2FAF8,mappings(a0)
	move.w	#$7400/$20,art_tile(a0)
	bsr.w	DisplaySprite
	cmpi.w	#$1064,(MainCharacter+x_pos).w	;check if character is at certain X value
	ble.s	Obj4c_rts			;if not, exit routine
	move.w	#0,(Ctrl_1_Logical).w		;CLear controls???
	move.w	#0,(Ctrl_2_Logical).w
	move.w	#0,(Ctrl_1).w
	move.w	#0,(Ctrl_2).w
	move.b	#1,(Control_Locked).w		;Disable Player input
	move.b	#$01,($FFFFF602).w	; force button "up" to be pressed on "Sonic's" controls
	move.w	#0,(Sonic_Look_delay_counter).w	;freeze look up counter at "0"
Obj4c_rts:
	rts

 

Code:

		ori.b	#%00000100,$01(a0)

 

Trash please

 

Yay! It works! Thanks Markey! I'm curious as to what that line actually does, though, I don't know an awful lot about the "ori" command, and I just generally like to know what all the lines I add do in the game, for easy editing.

EDIT: wow, so much ninjaing...

 

This wont fix your issue, but put this before you clear your addresses, moveq #0,d0 it processes them faster, so clear with d0, example like this move.w d0,(ctrl_1_logical).w.

Edit: I see its fixed but if your picky with processing this can be used. Also sorry I cant explain behind the scenes with this, Markeyjester I'm sure can explain it better.

 

The routine for displaying all of the sprites (known as "BuildSprites" in the original disassemblies), right above it, is a table of RAM addresses for scroll positions. The contents of the first byte of the object are loaded (i.e. $01(a0)), and in binary you get: DPRFPPVH. D for display, P for path (Sonic 2), R for single sprite, F for height flag, V for vertical flip, H for horizontal mirror, but these are irrelevant. PP is what we're dealing with. The two bits together allow for one of four possible results 00, 01, 10, or 11. This in essence decides which address to collect from that table we talked about before.

The table has four addresses:

• The first is blank (this is for flat objects that move on screen at their own control (like the HUD)).
• The second is the FG scroll positions (this causes the objects to display on screen based on the screen's FG coordinates (like in-level objects)).
• The third and forth are background scenery scroll positions (an example is Star Light Zone's FG pillar).

Your object did not display, because it was not using the screen's coordinates. Likely it was displaying outside of the screen. Using the OR instruction, we set it to 01, to use the FG coordinates.

Regarding the OR instruction see here for details.

 

Thanks for the clarification! Now that I know how it works, I might be able to use it in more creative ways!

 

Does anyone know how an object is situated in Sonic 3? Right now I have an object but it appears behind certain background elements like some trees and waterfalls. I'm thinking it's priority, especially since it's the one I just guessed on (I gave it $100 like with Sonic, it had 2 when implemented into the previous games but using that just made it freeze) though I'm commonly wrong.

 

If we are on the topic of S3K porting, I need information on how S3Ks Single object load differs from S2s. When porting S3K objects the single object call in the S3K code doesn't work in s2, and I'm confused on why. The object loads but not all parts of it.

Edit: I've checked many times in the code to see if maybe I didn't change the SSTs right, but didn't find anything.

Edit2: been wanting to fix the head trigger switch for my MGZ.

 

Trash.

 

How would I make sonic 2 load the credits? I looked through the code which involves S2's actual ending sequence, found where the pointers relating to the credits where referenced, and tried to jump to code around that, but it didn't help. I even tried changing the game mode to the ending sequence mode as I did it, but that went through the full cut scene at the end, which I don't want to use.

EDIT: Nevermind, I figured it out after some more out of the box experimentation.

 

So I got the clone driver v2 to work in my S2 hack (yay!) and have been using the default blank ram between $F100-$F5FF to run it. Thing is, my hack includes knuckles, who so happens to load his artwork over that exact range! Is there any way to move this to a more convienient place (like where Sonic actually stores his own art?)

 

You need to replace Knuckles' DPLC loading code with Sonic's, as shown here (GitHub disasm, but the concept still applies if you take the code from your disasm's LoadSonicDynPLC_Part2). Don't forget to replace the art file once you've done that.

The reason for this, is that Knuckles in KiS2 transfers his sprite from the S&K ROM into RAM so that it can be recolored to fit S2's palette before being transferred to VRAM. Sonic in S2 uses direct ROM to VRAM transfers.

 

Does anyone know how to add animated level tiles to Sonic 1 and have them show up in SonED2? I've tried figuring it out and searching for a tutorial online and I haven't been able to figure it out.