Basic Questions and Answers Thread

What? No! I'm not that nuts! It just functions as Classic Sonic 2 coop usually does; I haven't added overly fancy shit to it... I just want it to allow flying when 2 player takes control of tails, and disable it when the CPU takes over.

 

Wait in your 2-player vs there are sidekicks?

 

1-player coop mode... (although technically, this should also work in 2P as well, even though tail's AI never runs).

 

I see were your confused, I didn't mean change there object addresses during gameplay, I meant their RAM addresses.

 

So what should I have the game check to see if tails is in CPU mode or not?

 

Sidekick and CPU are technically the same thing.


Edit: (sidekick).w also equals CPU

 

Sidekick is tails location in the object ram, which doesn't help me check whether or not he's being player controlled at all. I'm trying to test when he is and isn't being controlled by player input. Am I making any sense?

 

Can't you check for player 2 pressing any button? Here I found this right at the top of TailsCPU_Control:


move.b (Ctrl_2_Held).w,d0 ; did the real player 2 hit something?
andi.b #button_up_mask|button_down_mask|button_left_mask|button_right_mask|button_B_mask|button_C_mask|button_A_mask,d0
beq.s + ; if not, branch

Or this for 2007 Xenowhirl


move.b (Ctrl_2_Held).w,d0 ; did the real player 2 hit something?
andi.b #$7F,d0
beq.s + ; if not, branch
Just change it to how you need it and put it at the start of your code.

 

The problem with performing the object solidity is that it doesn't confirm WHICH object you are standing on. If the emerald is loaded, and Sonic is standing on something (be it the emerald or not) the respective bit would set/clear regardless of whether or not he is actually on the emerald.

 

This is the exact same issue I am having with changing Sonic's animation script while standing on the tornado, His animations change while standing on the Turtloid badniks too.

 

No other platform objects load around the emeralds in my game so this isn't a issue, I wasn't sure if Pacguy was going to have other platform objects around them or not, but if he will then yes this won't work. I'm doing mine the S3K way Pacguy must be doing something different.
Edit: Tested it (without other platform objects around it) before hand and it worked, wouldn't have posted it up if it didn't work.


Edit2: Never mind still happens with a different platform object stood on around the emerald. I'll get it though, without creating a new RAM address lol

 

Okay if I query about this code as well? I'm trying to do a similar thing where Sonic can jump on the emerald and teleport to the level select (much like Proto Palace in the 2013 remake). I've used you coding on the Obj12 data, and thus far, it jumps to the level select, albeit not when you land on it, it seems to do so when you come to the area the object is loaded:

Code:

loc_20356:
 move.w #$20,d1
 move.w #$10,d2
 move.w #$10,d3
 move.w x_pos(a0),d4
 bsr.w SolidObject 
 lea (MainCharacter).w,a1 ; a1=character
 btst #3,status(a1)
 beq.s Obj12_Topof
 move.w x_pos(a0),d0
 andi.w #$FF80,d0
 sub.w (Camera_X_pos_coarse).w,d0
 cmpi.w #$280,d0
 bhi.w JmpTo16_DeleteObject
 bra.w JmpTo8_DisplaySprite
Obj12_End:
 rts
Obj12_Topof: 
 move.b #$28,(Game_Mode).w ; => LevelSelectMenu
 rts

 

The problem with performing the object solidity is that it doesn't confirm WHICH object you are standing on. If the emerald is loaded, and Sonic is standing on something (be it the emerald or not) the respective bit would set/clear regardless of whether or not he is actually on the emerald.




Based on this, it seems that only checks if sonic is standing in general when the object loads, regardless of the actual emeralds postion; my odd little method at least ensures that the player is in contact with the emerald before running the code, although it does require a ram flag.

 

Psi: Change, beq.s Obj12_Topof, into bne.s Obj12_Topof, when using btst/tst, treat branch if not equal and branch if equal, as their opposite, not sure why this is though. Answers both of your question on why my code seems wrong.

Edit: I can understand how you didn't trust my comment in the code, since I make a lot of errors.

 

Wha...? With btst and tst, treat equality as 'equal to zero'. So...


btst #3,status(a1)
beq.s Obj12_Topof

...means 'if bit 3 is not set (to 1)/if equal to 0, branch'.

Look, going again from the info here:


Status bitfield.

Counting from the least significant bit:
Bit Hex Description
0 $01 X Orientation. Clear is left and set is right.
1 $02 Y Orientation. Clear is right-side up, and set is upside-down
2 $04 Unknown or unused
3 $08 Set if Sonic is standing on this object.
4 $10 Unknown or unused
5 $20 Set if Sonic is pushing on this object.
6 $40 Unknown or unused
7 $80 Unknown or unused

'Set if stood on'

 

Thanks for explaining in full, Clownacy, appreciate it.

 

Thing with tst/btst is that they check for 0, and set the zero flag in the CCR accordingly (If=0, Z=1, If=/=0, Z=0). The beq instruction will branch if Z=1, and bne will branch if Z=0, hence why they may seem like they work opposite to each other. I think people just get confused because of the names of these branches (branch if equal/branch if not equal), and I think a better definition would be 'branch if equal/not equal to 0'.

 

I've set up the Shield in Sonic 2 to use the DPLC system from the shields in S3K, I'm now trying to make the Invincibility Stars load the same way as in S3K:


; ===========================================================================
; ----------------------------------------------------------------------------
; Object 35 - Invincibility Stars
; ----------------------------------------------------------------------------
; Sprite_1D97E:
Obj35:
move.l #ArtNem_Invincible_stars,d1 ; Called ArtNem but is really uncompressed.
move.w #$97C0,d2 ; $4BE*20
move.w #$220,d3 ; This is a guess, I don't know how to find this out.
jsr (QueueDMATransfer).l
moveq #0,d0
move.b objoff_A(a0),d0
move.w Obj35_Index(pc,d0.w),d1
jmp Obj35_Index(pc,d1.w) 
However it just results in this:



Anybody know where I'm going wrong?

 

While I don't know the actual cause of your problem, I see several other problems.

Look around here for stuff related to what you're doing, especially my posts there.

One major problem is the placement of your code: the code under Obj35 will be processed on every frame, meaning that art is gonna be constantly transferred. Really bad idea. S3K doesn't make it too obvious, what, with its ditching of the routine system, but the code you added is normally only processed in the 'init' stage, meaning your code should go under loc_1D9A4 (pretty much Obj35_Init), as it's only processed the once.

Also, for determining what should go in d3, try something like this:


ArtNem_Invincible_stars: BINCLUDE "art/nemesis/Invincibility stars.unc"
ArtNem_Invincible_stars_end

...and:

Code:

	move.w	#(ArtNem_Invincible_stars_end-ArtNem_Invincible_stars)/2,d3

 

Thanks for the insight, moved the code and tried out that method of determining d3. From this I can gather the problem lies elsewhere.

EDIT: Fixed this, another mistake down to following the S3K coding too closely and removing this line:


move.w #make_art_tile(ArtTile_ArtNem_Shield,0,0),art_tile(a1) 
Which I guess resulted in the object using the first tiles in the VRAM instead of the intended art.

Now all I have to fix is the shield causing the game to crash in Regen.

I installed Flamewing's Debugger and the result was this:



Which lead me to this line being the cause of the crash:


move.l #ArtNem_Shield,objoff_2B(a0)

I don't know why this line is leading to an error.