Basically, if S3 mode is enabled, S&K uses a different set of data for e.g. title screen, level order, and other things that are different. It also enables the S3-only level music, which isn't present in S&K standalone, by pointing it to addresses in the S3 cartridge. (You can verify this by going into S&K's level select, then trying to play S3 music - it won't do anything.) For S2 mode, the 256 KB ROM gets full control of everything. It loads data from the S2 cartridge, but everything else is from the extra ROM. (They didn't have enough space in the 2 MB main ROM, hence the need for an extra ROM and the control registers)
Oh ok, great. Now I know! Looks like the way the lock-on works isn't dependent on the way the Genesis works either. Thanks Gerbil.
With knowing how this works. Do you know why exactly S1 and Knuckles couldn't work like the others? Obviously they wanted the avoid the palette issues... but they could've simply used Knuckles palette over Sonic's and made everything else that was normally blue, grey instead... much like how they did with Sonic 2... e.g. the grey shield. Was there more to that? The only thing off the top of my head is that the art limit in Sonic 1 would need to be expanded to fit Knuckles. Could this not have been done? EDIT - Having been working with putting Knuckles in Sonic 1 lately... I'm surprised I forgot this... The above palette fix doesn't work with the emeralds... I'm sure there are other things I'm overlooking as well.
As I understand it there are lots of issues. There are different chunk sizes, the palette problems being worse than in S2, a lack of time to do both.... + - gliding onto conveyor belts? =P
I have tried porting software scrolling Routines from Sonic 1 into Sonic 2 before, and had some trouble with it. Today, I decided to give if another go, this time using KingOfHarts HG disassembly of Sonic 1 as a base. Well, after some work, I got my first Software Scrolling routine ported from Sonic 1; I ported Green Hill Zone's. Originally, I was using the Nick Arcade prototype's GHZ software scrolling, but I managed to got Sonic 1's working just as well, so I'm using that. I moved on to Zone 2 (Which is supposed to use Marble Zone's software scrolling), and that's where I'm having a problem. Currently, this is what I have Code (Text): SwScrl_MBZ: move.w (Camera_X_pos_diff).w,d4 ext.l d4 asl.l #6,d4 move.l d4,d1 asl.l #1,d4 add.l d1,d4 moveq #2,d6 bsr ScrollBlock3 move.w (Camera_X_pos_diff).w,d4 ext.l d4 asl.l #6,d4 moveq #6,d6 bsr ScrollBlock5 move.w (Camera_X_pos_diff).w,d4 ext.l d4 asl.l #7,d4 moveq #4,d6 bsr ScrollBlock4 move.w #$200,d0 move.w (Camera_Y_pos).w,d1 subi.w #$1C8,d1 bcs.s loc_6590 move.w d1,d2 add.w d1,d1 add.w d2,d1 asr.w #2,d1 add.w d1,d0 loc_6590: move.w d0,(Camera_BG2_Y_pos).w move.w d0,(Camera_BG3_Y_pos).w bsr ScrollBlock2 move.w (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w move.b (Scroll_flags_BG).w,d0 or.b (Scroll_flags_BG2).w,d0 or.b d0,(Scroll_flags_BG3).w clr.b (Scroll_flags_BG).w clr.b (Scroll_flags_BG2).w lea (TempArray_LayerDef).w,a1 move.w (Camera_X_pos).w,d2 neg.w d2 move.w d2,d0 asr.w #2,d0 sub.w d2,d0 ext.l d0 asl.l #3,d0 divs.w #5,d0 ext.l d0 asl.l #4,d0 asl.l #8,d0 moveq #0,d3 move.w d2,d3 asr.w #1,d3 move.w #4,d1 loc_65DE: move.w d3,(a1)+ swap d3 add.l d0,d3 swap d3 dbf d1,loc_65DE move.w (Camera_BG3_X_pos).w,d0 neg.w d0 move.w #1,d1 loc_65F4: move.w d0,(a1)+ dbf d1,loc_65F4 move.w (Camera_BG2_X_pos).w,d0 neg.w d0 move.w #8,d1 loc_6604: move.w d0,(a1)+ dbf d1,loc_6604 move.w (Camera_BG_X_pos).w,d0 neg.w d0 move.w #$F,d1 loc_6614: move.w d0,(a1)+ dbf d1,loc_6614 lea (TempArray_LayerDef).w,a2 move.w (Camera_BG_Y_pos).w,d0 subi.w #$200,d0 move.w d0,d2 cmpi.w #$100,d0 bcs.s loc_6632 move.w #$100,d0 loc_6632: andi.w #$1F0,d0 lsr.w #3,d0 lea (a2,d0),a2 Bg_Scroll_X: lea (Horiz_Scroll_Buf).w,a1 move.w #$E,d1 move.w (Camera_X_pos).w,d0 neg.w d0 swap d0 andi.w #$F,d2 add.w d2,d2 move.w (a2)+,d0 jmp loc_66EA(pc,d2) Loop_Bg_Scroll_X: move.w (a2)+,d0 loc_66EA: move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ move.l d0,(a1)+ dbf d1,Loop_Bg_Scroll_X rts If anyone is willing to help, I posted what each ScrollBock means below in terms of what routine it correlates to in my Sonic 2 disassembly: ScrollBlock1 is SetHorizVertiScrollFlagsBG ScrollBlock2 is imported from Soinc 1, I'll post that below. ScrollBlock3 is SetHorizScrollFlagsBG ScrollBlock4 is SetHorizScrollFlagsBG2 ScrollBlock5 is SetHorizScrollFlagsBG3 My imported ScrollBlock2 looks like this: ScrollBlock2: move.w (Camera_BG_Y_pos).w,d3 move.w d0,(Camera_BG_Y_pos).w move.w d0,d1 andi.w #$10,d1 move.b (Verti_block_crossed_flag_BG).w,d2 eor.b d2,d1 bne.s ++ eori.b #$10,(Verti_block_crossed_flag_BG).w sub.w d3,d0 bpl.s + bset #0,(Scroll_flags_BG).w rts + bset #1,(Scroll_flags_BG).w + rts Anyone know what might be wrong?
My own implementation ended in a similar way, and has yet to be successful. If I've implemented yours properly, we're having the same problem, except for the misplaced squares all over the place that eventually start overwriting the background with the underground art, and some weird shaking. Spoiler Curiously, my REV00 port works perfectly. An interesting thing to note is that the REV00 code uses ScrollBlock3 which is actually REV01's ScrollBlock2. ScrollBlock2, from what I understand, handles MZ's unique Y-Scroll, and isn't used by any other zones except for REV00's GHZ. There's no need to port Bg_Scroll_X, it's already in Sonic 2 under the name SwScrl_HPZ_Continued. The art is misplaced, you're probably already aware of that. From what I've observed, some underground art is above the first cloud layer, several clouds are on the same layer as the mountains, and the underground art doesn't even fully appear, with the underground section being set against the same corrupt overworld art on loop, these copies, however, don't scroll. That said, I'm curious about what handles mapping background art. Since the REV00 background, which depends on ScrollBlock3/2, works, I would assume that ScrollBlock2 has been ported correctly, however, if you comment out the branch to ScrollBlock2, along with the obvious disabling of the Y-Scroll, the underground art above the highest cloud layer vanishes, but the clouds on the same layer as the mountains remain, also, in your case those weird squares vanish. Here's my own attempt, where I simply stuck to finding equivalent RAM variables and labels, keeping the code vanilla: REV00 Spoiler Code (Text): SwScrl_MZ: move.w (Camera_X_pos_diff).w,d4 ext.l d4 asl.l #6,d4 move.l d4,d1 asl.l #1,d4 add.l d1,d4 moveq #0,d5 bsr.w SetHorizVertiScrollFlagsBG move.w #$200,d0 move.w (Camera_Y_pos).w,d1 subi.w #$1C8,d1 bcs.s loc_6402 move.w d1,d2 add.w d1,d1 add.w d2,d1 asr.w #2,d1 add.w d1,d0 loc_6402: move.w d0,(Camera_BG2_Y_pos).w bsr.w ScrollBlock2 ; REV00 ScrollBlock3 move.w (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w lea (Horiz_Scroll_Buf).w,a1 move.w #223,d1 move.w (Camera_X_pos).w,d0 neg.w d0 swap d0 move.w (Camera_BG_X_pos).w,d0 neg.w d0 loc_6426: move.l d0,(a1)+ dbf d1,loc_6426 rts ; End of function SwScrl_MZ REV01 Spoiler Code (Text): SwScrl_MZ: move.w (Camera_X_pos_diff).w,d4 ext.l d4 asl.l #6,d4 move.l d4,d1 asl.l #1,d4 add.l d1,d4 moveq #2,d6 bsr SetHorizScrollFlagsBG move.w (Camera_X_pos_diff).w,d4 ext.l d4 asl.l #6,d4 moveq #6,d6 bsr SetHorizScrollFlagsBG3 move.w (Camera_X_pos_diff).w,d4 ext.l d4 asl.l #7,d4 moveq #4,d6 bsr SetHorizScrollFlagsBG2 move.w #$200,d0 move.w (Camera_Y_pos).w,d1 subi.w #$1C8,d1 bcs.s loc_6590 move.w d1,d2 add.w d1,d1 add.w d2,d1 asr.w #2,d1 add.w d1,d0 loc_6590: move.w d0,(Camera_BG2_Y_pos).w move.w d0,(Camera_BG3_Y_pos).w bsr ScrollBlock2 move.w (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w move.b (Scroll_flags_BG).w,d0 or.b (Scroll_flags_BG2).w,d0 or.b d0,(a3) clr.b (Scroll_flags_BG).w clr.b (Scroll_flags_BG2).w lea (TempArray_LayerDef).w,a1 move.w (Camera_X_pos).w,d2 neg.w d2 move.w d2,d0 asr.w #2,d0 sub.w d2,d0 ext.l d0 asl.l #3,d0 divs.w #5,d0 ext.l d0 asl.l #4,d0 asl.l #8,d0 moveq #0,d3 move.w d2,d3 asr.w #1,d3 move.w #4,d1 loc_65DE: move.w d3,(a1)+ swap d3 add.l d0,d3 swap d3 dbra d1,loc_65DE move.w (Camera_BG3_X_pos).w,d0 neg.w d0 move.w #1,d1 loc_65F4: move.w d0,(a1)+ dbra d1,loc_65F4 move.w (Camera_BG2_X_pos).w,d0 neg.w d0 move.w #8,d1 loc_6604: move.w d0,(a1)+ dbra d1,loc_6604 move.w (Camera_BG_X_pos).w,d0 neg.w d0 move.w #$F,d1 loc_6614: move.w d0,(a1)+ dbra d1,loc_6614 lea (TempArray_LayerDef).w,a2 move.w (Camera_BG_Y_pos).w,d0 subi.w #$200,d0 move.w d0,d2 cmpi.w #$100,d0 bcs.s loc_6632 move.w #$100,d0 loc_6632: andi.w #$1F0,d0 lsr.w #3,d0 lea (a2,d0),a2 bra SwScrl_HPZ_Continued ; End of function SwScrl_MZ ScrollBlock2 Spoiler Code (Text): ScrollBlock2: move.w (Camera_BG_Y_pos).w,d3 move.w d0,(Camera_BG_Y_pos).w move.w d0,d1 andi.w #$10,d1 move.b (Verti_block_crossed_flag_BG).w,d2 eor.b d2,d1 bne.s ++ eori.b #$10,(Verti_block_crossed_flag_BG).w sub.w d3,d0 bpl.s + bset #0,(Scroll_flags_BG).w rts + bset #1,(Scroll_flags_BG).w + rts ; End of function ScrollBlock2 EDIT: Quoted due to new page.
I tried both routines, though I'm oping to get 01 working, since revision 01 had better scrolling. Incidentally, your Revision 00 port is working very strangely for me. The background itself is scrolling correctly, but it reacts to every movement Sonic makes, and one if starts scrolling, it doesn't stop. Also, the faster Sonic goes, the faster the background moves while standing still. This leads me to believe I may have labeled a ScrollBlock wrongly after all, even though GHZ's software scroll works. As for Revision 01, in short, it's working better, I must have gotten an equate wrong or something. The randomly appearing blocks are gone in your version, and the scrolling itself seems to be working properly, but I am still getting some symptoms: The cloud layer and underground layers are still appearing wrong for me. That's the only bug I'm experiencing at the moment minus the Labyrinth Zone ripple, which I had put in Hidden Palace and will be easy enough to fix (Just check the water flag). Are you getting similar symptoms?
Yes, my REV01 has never fully worked, sorry if I made you think I was providing you with a fix. But the REV00 issues... Did you use the provided ScrollBlock2 and unmodified SetwhateverScrollFlags? I had ported the scrolling data from my largely modified disassembly to a fresh HG disassembly a while back with no issues. Could you try there and see if the code works? I just recreated the squares. At some point, I don't remember when or why, but I... well, look here: Yours Code (Text): loc_6590: move.w d0,(Camera_BG2_Y_pos).w move.w d0,(Camera_BG3_Y_pos).w bsr ScrollBlock2 move.w (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w move.b (Scroll_flags_BG).w,d0 or.b (Scroll_flags_BG2).w,d0 or.b d0,(Scroll_flags_BG3).w <------- clr.b (Scroll_flags_BG).w clr.b (Scroll_flags_BG2).w lea (TempArray_LayerDef).w,a1 move.w (Camera_X_pos).w,d2 I was cross comparing our code when I found this: Mine Code (Text): loc_6590: move.w d0,(Camera_BG2_Y_pos).w move.w d0,(Camera_BG3_Y_pos).w bsr ScrollBlock2 move.w (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w move.b (Scroll_flags_BG).w,d0 or.b (Scroll_flags_BG2).w,d0 or.b d0,(a3) <------ clr.b (Scroll_flags_BG).w clr.b (Scroll_flags_BG2).w lea (TempArray_LayerDef).w,a1 move.w (Camera_X_pos).w,d2 Why the heck did I do that? Whatever it did, changing it back to Scroll_flags_BG3 caused the squares to begin appearing! Scroll_flags_BG3 is used by ScrollBlock5 aka SetHorizScrollFlagsBG3, however, commenting out the branch to it doesn't affect the squares, it just disables the mountain layer's scrolling. On a side note, not to be rude, but aren't you supposed to not quote posts directly above yours? I only quoted because of the page-break.
I kinda just hit the quote button out of instinct. My bad. Unfortunately, the effects seem to carry even into an otherwise unmodified disassembly for some reason. Are you sure you didn't change something the pasted version by mistake? My Scroll Block 2 is the same one you posted to me, and in fact, all the scrolling routines in my disassembly are unmodified besides adding a secondary label, ScrollBlock#:
Ooooooooops, I'm an idiot, when renaming SwScrl_MZ from Deform_MZ I accidentally deleted the first command, sorry, corrected: Code (Text): SwScrl_MZ: move.w (Camera_X_pos_diff).w,d4 ext.l d4 asl.l #6,d4 move.l d4,d1 asl.l #1,d4 add.l d1,d4 moveq #0,d5 bsr.w SetHorizVertiScrollFlagsBG move.w #$200,d0 move.w (Camera_Y_pos).w,d1 subi.w #$1C8,d1 bcs.s loc_6402 move.w d1,d2 add.w d1,d1 add.w d2,d1 asr.w #2,d1 add.w d1,d0 loc_6402: move.w d0,(Camera_BG2_Y_pos).w bsr.w ScrollBlock3 move.w (Camera_BG_Y_pos).w,(Vscroll_Factor+2).w lea (Horiz_Scroll_Buf).w,a1 move.w #223,d1 move.w (Camera_X_pos).w,d0 neg.w d0 swap d0 move.w (Camera_BG_X_pos).w,d0 neg.w d0 loc_6426: move.l d0,(a1)+ dbf d1,loc_6426 rts ; End of function SwScrl_MZ EDIT: I'm getting 404s when trying to download a fresh disassembly... strange.
I'm suprised I missed that too. I'm hoping at some point I'll be able to figure out the Rev 01 effects, but at least this works perfect. Thank you very much, Clownacy! It works fine now.
As many who browse this thread would know, I'm putting a basic Knuckles in Sonic 1 hack together... to be ported to my Sonic 1 REV C project. I've run into a slight issue however, as it relates to DPLC's. For one particular frame in Knuckles' Ending specific sprites... THIS ONE ... I've got a DPLC request that calls for $1A tiles to be loaded to VRAM. Said request looks like the following: Code (Text): EndKnuxDynPLC_51A: dplcHeader dplcEntry 3, $38A ; standard sprite dplcEntry $10, $38D ; standard sprite dplcEntry 1, $39D ; standard sprite dplcEntry 4, $39E ; standard sprite dplcEntry 2, $467 ; SOCK OVERLAY EndSonicDynPLC_51A_End The two added tiles at the bottom are for an overlay to make Knuckles' socks appear green. This appears properly in EVERY other sprite except this one. This clipping from the VRAM shows why: The long yellow rectangle was added by me, and reflects the empty VRAM space where the tiles should be loaded... there's more than enough for 3 tiles... There are 3 tiles NOT loaded to VRAM, the 2 overlay tiles, and one of Knuckles original tiles that is supposed to go on the bottom part of his fist... take a close look at his hand in this screenshot. You'll also notice the socks aren't green, rather they are blue... this is the result of the lacking overlay tiles. I've expanded the art limit, and have NOTHING being written to that part of VRAM so I don't know what the deal is... These are custom Knuckles sprites made specifically to counter the palette limitation... the standard ones used in normal zone gameplay appear correctly, EXCEPT for this frame as well... with the one tile for his fist not appearing. So yea I'm stumped...
The interesting thing about this is that only 17 (hex) tiles have transfered in your VRAM image there. Which just so happens to be Sonic 1's original Sonic art transfer amount. Code (Text): move.l #$94019370,(a5) Where the "01" and "70" are 0170 together. This is 02E0 bytes divided by 2 (a.k.a. 17 tiles), you'll find these in various places in the v-blank routines of Sonic 1 (loc_CD4, loc_DAE, loc_ED8 & loc_FAE). To increase the number of tiles is to add 10 to the 0170 for every additional tile you want transfered each time. BUT... Given that you've shown me a macro tells me this is probably based on an up to date disassembly where the lables may differ, and the DMA setup isn't raw assembly. I did try to find a recent disassembly, but I don't know which one yours is, and the HG thingy seems to be down anyway. EDIT: I've just realised that you've said you have "expanded the art limit", I don't know if this above is what you meant, so I'll leave it above just in-case. The only other explanation I can think of is the RAM space where Sonic's art is loaded to before it is transfered. The DPLC loading routine in the original Sonic 1 game loads art from ROM to RAM at C800 - CADF (I.e. FFC800 - FFCADF) holding the 17 tiles before the transfer. You're attempting to transfer 1A tiles, this means you need 340 bytes of RAM storage (I.e. from RAM C800 - CB3F). If RAM CAE0 - CB3F is used by anything else (which could be a posibility), then your art might just be overwritten in RAM before it has a chance to transfer. However, this does depend on whether or not you've changed the art loading routine. I know a few people have resorted to porting Sonic 2's dynamic art loading system which causes the game to make a DMA transfer directly from ROM to VRAM, instead of ROM to RAM to VRAM. I think we're gonna need more info about your game/source.
I use the HG disasm of Sonic 1. If it's any help, the HG port of your Sonic 1-Two Eight project that I posted uses the same source, so aside from the obvious changes there, it's identical to the one you'd normally find on HG anyway. The macro is MainMemory's macro, used for mappings and DPLC's... to the best of my knowledge... this only makes editing the mappings and DPLC's easier... because I don't think it edits anything else in that regard, though I could be mistaken. By "expanding the art limit"... I apologize, I should've been more specific. I meant following this guide: http://info.sonicret...s_and_art_limit Ironically, or coincidentally enough... if there is no irony there to be had, it is your old guide. Aside from that, I haven't changed much else... other than removing points from the Main PLC to make room for the tiles (Not the most feasible solution but I can fix that at a later time...) I'll try looking at RAM that I have available. I can think of plenty of ways to free up RAM so that's not too much of an obstacle... luckily for me, everything is equated so moving stuff around is also a piece of cake. I'll give it a go and report back. EDIT: I went the route of using the Sonic 2 DMA transfer... Took a page out of ReadySonic for that one, actually, so thanks to Mercury on that note. Now it all works out well. Thanks for the tips Markey!
Then if that be it the case, I would make the immediate assumption that it is in fact the transfer size in the v-blank routines. Yours might be... Code (Text): DMA $02E0,SonicArtRAM,$70000083 Or at least something similar like that, where the 2E0 is the size of the art transfer. Simply increasing the value should solve the problem.
Code (Text): writeVRAM v_sgfx_buffer,$2E0,vram_sonic ; load new Sonic gfx I did notice that... those lines get replaced with what I ultimately went with. Thank you for the tip though!
Okay, so I am back again, jumping into a new hacking experience, and I need a little bit of help. First thing is something pretty simple. I want a single level in my Sonic 2 hack (Pretty much, for a Cutscene.), where the characters (Sonic and Tails normally), both have a hard speed cap of $600. While I do have some code for this, it's literally comparing the MainCharacter's inertia to $600, followed by the Sidekick. Is there a better way to do this? This is my current code, which is only used for going left, but it wouldn't be hard to make it work for left AND right.. It'd just be sloppy and waste several cycles I could probably save. Code (Text): cmpi.w #-$600,(MainCharacter+inertia).w bgt.s + move.w #-$600,(MainCharacter+inertia).w + cmpi.w #-$600,(Sidekick+inertia).w bgt.s + move.w #-$600,(Sidekick+inertia).w + Any wisdom on making this could quicker to run while achieving the same purpose would be greatly appreciated. Now, my second question.. Is.. Not so easy. As far as I can tell. I'm trying to port a platform object from Sonic 1, and while the platform appears properly now, if Sonic touches the top, he gets teleported a million, billion miles into the sky away. The object of $2F (The sinking and rising platforms from Marble Zone). Is there any advice on how to change the code so it works as needed? Here is an excerpt of code that handles the collision: Code (Text): ; =========================================================================== LGrass_Slope: ; XREF: LGrass_Action moveq #0,d1 move.b width_pixels(a0),d1 addi.w #$B,d1 movea.l objoff_30(a0),a2 move.w x_pos(a0),d2 bsr.w SlopeObject bra.s LGrass_Display ; =========================================================================== LGrass_Solid: ; XREF: LGrass_Action moveq #0,d1 move.b width_pixels(a0),d1 addi.w #$B,d1 move.w #$20,d2 cmpi.b #2,mapping_frame(a0) bne.s loc_AF8E move.w #$30,d2 loc_AF8E: movea.l $30(a0),a2 bsr.w SolidObject LGrass_Display: ; XREF: LGrass_Action bsr.w DisplaySprite bra.w LGrass_ChkDel If more information is needed, please drop me a PM, and I'll give you all the code I have for the object. It should be noted that my ExitPlatform label is loc_19D62 in my s2.asm. If anyone knows anything, I would really appreciate help, I have pretty much no experience with setting up platform objects for Sonic 1, and minimal experience with doing so for Sonic 2.
Code (Text): move.w #$0600,d1 ; prepare speed cap amount move.w (MainCharacter+inertia).w,d0 ; load character's X speed cmp.w d1,d0 ; is the character moving right too fast? bgt.s MainXRight ; if so, branch add.w d1,d0 ; advance left maximum speed to 0000 bpl.s MainXOK ; if the result is positive, speed is slower than -600 neg.w d1 ; reverse speed cap to negative maximum (left) MainXRight: move.w d1,(MainCharacter+inertia).w ; save new speed MainXOK: move.w #$0600,d1 ; prepare speed cap amount move.w (Sidekick+inertia).w,d0 ; load character's X speed cmp.w d1,d0 ; is the character moving right too fast? bgt.s SideXRight ; if so, branch add.w d1,d0 ; advance left maximum speed to 0000 bpl.s SideXOK ; if the result is positive, speed is slower than -600 neg.w d1 ; reverse speed cap to negative maximum (left) SideXRight: move.w d1,(Sidekick+inertia).w ; save new speed SideXOK: For a reasonably optimised speed cap, probably not the best and not as small, but certainly quicker. As for your platform issue, looking at the code, it doesn't seem accurate to the original. For example. Code (Text): movea.l $30(a0),a2 bsr.w SolidObject When in fact, the original Sonic 1 code does not call the routine "SolidObject". Instead it calls "SolidObject2F", a special type of SolidObject routine designed specifically for object 2F to help deal with the sloping in conjunction with the solidity.
Thank you for helping me with the code for the Speed Cap. After you told be about SolidObject2F's special routine, I decided to try porting it once again. I tried this in the past, and had no success, but my ASM knowledge is better now, so I have had *partial* success. For one, the routine is from Sonic 1, so Tails doesn't collide with it. I should be able to fix that with relative ease though, if I just compare to the other solid object routines. What gets me, is when Sonic leaves the platform: Sonic does not fall off of the platform when walking off of it. I will post my SolidObject2F, though I'm sure that's not the problem. Code (Text): SolidObject2F: ; XREF: Obj2F_Solid lea (MainCharacter).w,a1 tst.b Render_Flags(a0) bpl.w Solid_Ignore move.w X_pos(a1),d0 sub.w X_pos(a0),d0 add.w d1,d0 bmi.w Solid_Ignore move.w d1,d3 add.w d3,d3 cmp.w d3,d0 bhi.w Solid_Ignore move.w d0,d5 btst #0,Render_flags(a0) ; is object horizontally flipped? beq.s Solid2f_notflipped ; if not, branch not.w d5 add.w d3,d5 Solid2f_notflipped: lsr.w #1,d5 moveq #0,d3 move.b (a2,d5.w),d3 sub.b (a2),d3 move.w Y_pos(a0),d5 sub.w d3,d5 move.b Y_Radius(a1),d3 ext.w d3 add.w d3,d2 move.w Y_pos(a1),d3 sub.w d5,d3 addq.w #4,d3 add.w d2,d3 bmi.w Solid_Ignore move.w d2,d4 add.w d4,d4 cmp.w d4,d3 bcc.w Solid_Ignore bra.w loc_19A2E For you, Solid_Ignore would be loc_19AC4. Edit: I removed a bunch of unnecessary stuff.. Working with the object for a while, I realized the problem must be my SolidObject routine. I'n not quite sure what I need to do to make it work, but I'll keep trying.
Say, notice something here? JAP Sonic 1 Spoiler Sonic 1 Two-Eight HG Spoiler My ROM Spoiler It's those clouds near the mountain, along with where some of the cloud 'cuts off' (to the left of the second tallest pillar in the Two-Eight screenshot)! Sonic 1 Two-Eight (main change being 128x128 chunks) works fully with the REV00 background, but not the REV01, just as our ROMs (also 128x128 chunk) don't.
