Any idea how it's translating the frame however. It seems to be about frame $D8 or $D9. What is the sum going into making that $1B4?
$1B4 = $DA * 2. d0 has been doubled earlier on, with Code (ASM): add.w d0,d0 This means that frames before $DA are in the first file, and frames starting at and including $DA are in the second file.
What exactly do you need help understanding? The basic deformation of the background chunks? OR how tiles are loaded into certain parts of the chunks to give the illusion of layered backgrounds?
Is there any advisory place to put the coding for a new object in Sonic 3's asm? Same for it's the location of it's art files. It's an object that will be used in all levels and will connected to the player when used.
I talked with Hitaxas and I did this thing to help his issue, if you get bad underwater palette, it's because of a relationship of Normal_Palette and Underwater_Pallete, to fix this: Find PalLoad3_Water and replace: Code (Text): suba.l #$A80,a3 With this: Code (Text): suba.l #(Normal_palette-Underwater_palette)-$80,a3 Find PalLoad4_Water and replace: Code (Text): suba.l #$B00,a3 With this: Code (Text): suba.l #(Normal_palette-Underwater_palette),a3 You just have to take care of where you'll put the underwater address but overally this fix should work normally. E-122-Psi: Maybe it's a bad programming practice but I put my art files on the lock-on area and my objects after a rts of a known object and/or routine. It's not that clean but worked for me so far, albeit I plan to clean things up later on.
Okay, progression made. I've finally got the stinking projectile to load in Sonic 1, however there's some problems programming directional change. When the player turns around, there is a delay after it loads (ie. if you're facing left it still goes right a bit then back left) and attempting to branch it to go vertical makes TWO objects that stop in their tracks. Code (ASM): move.b #$20,$30(a0) ; distance laser will travel cmpi.b #$25,$1C(a1) ; is NICOLE attack being performed? beq.w ObjDE_DownwardNICOLE ; if not, branch move.w #$600,$10(a0) ; speed of laser jmp ObjDE_ForwardNICOLE ObjDE_DownwardNICOLE: move.w #$600,$12(a0) ; speed of laser ObjDE_ForwardNICOLE: add.w #$10,8(a0) btst #0,$22(a1) beq.s Obj10_Cont neg.w $10(a0) sub.w #$20,8(a0) Obj10_Cont: EDIT: Skip that, I've managed to edit the coding to get the horizontal change working, though I still can't make it work downward. In the state I've got it now it is stationary and in double form: Code (ASM): move.b #$18,$30(a0) ; distance laser will travel cmpi.b #$25,$1C(a1) ; is NICOLE attack being performed? beq.s Obj10_DownwardNICOLE ; if not, branch move.w #$600,$10(a0) ; speed of laser add.w #$10,8(a0) btst #0,$22(a1) beq.s Obj10_Cont neg.w $10(a0) sub.w #$20,8(a0) jsr Obj10_Cont Obj10_DownwardNICOLE: move.w #$600,$12(a0) ; speed of laser Obj10_Cont: It's supposed to be one object moving downward. EDIT: Never mind. Problem fixed. :D
So, um, how exactly would I be able to configure the _smps2asm_inc.asm file to use a custom DAC table? For Sonic - Into the Void, I have a MegaPCM DAC table set up which is basically the S3K/3D table from the Clone Driver v2 slightly modified and rearranged to fit vanilla Sonic 1's music, and upon looking at those samples in the smps2asm file, it's kind of confusing. Whoever answers this, I could PM you the DAC table if you wish. I just need the knowledge on how to work with the sample listings.
Is anyone experienced with the coding for the Final Zone boss (obj 85 I presume)? I know it needs to be specifically edited for anything to hit it, but is there any other process that is linked to Sonic's object? I've tried getting it to respond to another object, and Eggman gets stuck in perpetual 'hit mode'.
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. The line that makes this happen is: Code (Text): 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).
I'm afraid there's not enough information to be sure on what it is that's happening. Now while; Code (Text): add.w (MainCharacter+y_pos).w,d3 ...is understood as the main cause of the problem. it could simply be a by product of the real cause. Could you share the rest of the code that belongs with that line (Just to give it some context)? It may help us to understand why that line might be causing this chain reaction.
Sure, here's what I have: Code (Text): Obj4D: moveq #0,d0 move.b routine(a0),d0 move.w Obj4D_Index(pc,d0.w),d1 jmp Obj4D_Index(pc,d1.w) Obj4D_Index: offsetTable offsetTableEntry.w Obj4D_Init ; 0 offsetTableEntry.w Obj4D_Main ; 2 Obj4D_Init: addq.b #2,routine(a0) move.l #Obj7E_MapUnc_1E1BE,mappings(a0) move.b #4,render_flags(a0) move.b #1,priority(a0) move.b #$18,width_pixels(a0) move.w #make_art_tile(ArtTile_ArtNem_SuperSonic_stars,0,0),art_tile(a0) move.b #6,mapping_frame(a0) btst #high_priority_bit,(MainCharacter+art_tile).w beq.s Obj4D_Main bset #high_priority_bit,art_tile(a0) Obj4D_Main: tst.b (Super_Sonic_flag).w beq.w locret_19382 subq.b #1,anim_frame_duration(a0) bpl.s + move.b #1,anim_frame_duration(a0) addq.b #1,mapping_frame(a0) cmpi.b #3,mapping_frame(a0) bcs.s + move.b #0,mapping_frame(a0) moveq #0,d0 move.w d0,objoff_30(a0) move.w d0,objoff_34(a0) + move.b angle(a0),d0 addi.b #-$10,angle(a0) jsr (CalcSine).l asl.w #3,d0 asl.w #3,d1 move.w d0,x_vel(a0) move.w d1,y_vel(a0) move.w x_vel(a0),d0 add.w d0,objoff_30(a0) move.w y_vel(a0),d1 add.w d1,objoff_34(a0) move.b objoff_30(a0),d2 ext.w d2 btst #0,(MainCharacter+status).w beq.s + neg.w d2 + move.b objoff_34(a0),d3 ext.w d3 add.w (MainCharacter+x_pos).w,d2 add.w (MainCharacter+y_pos).w,d3 move.w d2,x_pos(a0) move.w d3,y_pos(a0) jmp (DisplaySprite).l locret_19382: rts
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.
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: Code (ASM): 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.
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.
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.
So you need to move them down to Sonic's Y_pos? why not try something like this: Code (ASM): move.w y_pos(a1),y_pos(a0) Assuming that Sonic is object a0 and the stars are a1, this should work out.
