Back again. So I'm following the GitHub portion of this guide to port S2 level art loading to S1 and I'm using KensSharp 1.2 from Clownacy for the decomp/comp. I've decompressed the main 8x8 .bin level art files. That's where I'm at right now. Easy. But before I go further, I want to use "Superfast Kos, v2" rather than the original. Can I just swap out the Kosinski Decompression.asm in my _inc folder with the newer version under the same name? And on another note, when I compress my .bin files to Kosinski, will they work hand-in-hand with the updated decomp algorithm? And before I get any more annoying, what exactly is Kosinski+ compression in KensSharp (is it actually for the same newer algorithm)? I'm interested in compressing to that if I can. I'm too many years too late onto the hacking scene. But I'm really feeling it right now and I'm so close to finishing the project I've been working on little by little for the past month. :v:
I think the credit for KENSSharp more belongs to FraGag and flamewing than me. You should be able to swap out the decompressor without any problems. Just make sure you're using the one suited for your assembler (asm68k and AS require their own versions). I think the decompressor you linked to might be out of date. The latest version is kept on GitHub these days. Kosinski files should work with any Kosinski decompressor. Otherwise they wouldn't be Kosinski decompressors in the first place. Kosinski+ is an enhanced (but binary-incompatible) version of Kosinski. Kosinski's format is pretty unoptimised for the 68k. If anything, I think it was made for the x86. Kosinski+ tweaks Kosinski's format to get the maximum decompression speed possible without sacrificing compression size, but that means Kosinski+ files won't work with regular Kosinski decompressors. Though I should point out, Kosinski+ is a little fragmented right now. Not too long ago, the format was changed again. So technically there are two different version of Kosinski+ now, which aren't compatible with each other. The latest version of the decompressor on GitHub is for the second version, but KENSSharp only supports the first version. This link should take you to the last version of the decompressor to support the original Kosinski+. Eventually, if the format doesn't change again, KENSSharp will be updated to support version 2.
Thanks for the lengthy explanation. In that case I'll stick with the KosDec from GitHub since it's the updated version by vladikcomper & friends like I wanted. It should work just fine with the latest S1 GitHub disasm and it's a vast improvement over Nemesis anyway. Thanks for the help.
I have a problem that I do not know how to solve, I added the green hill zone in Sonic 2, I also added the collision of Sonic 1, everything works well except the loops, does anyone know what I can do for the loops to work
Did you import the level with proper dual-layer collision for the loops? Did you add the pathswapper objects? Copy them from another level if you don't know how to set them up.
So yeah... I followed the GitHub portion of the guide to a 'T' from start to finish and have a few snags for some reason not mentioned in the guide. First off: Does "comment out" mean to delete, erase and/or remove? ; --------------------------------------------------------------------------- ; Pattern load cues - Green Hill ; --------------------------------------------------------------------------- PLC_GHZ: dc.w ((PLC_GHZ2-PLC_GHZ-2)/6)-1 plcm Nem_GHZ_1st, 0 ; GHZ main patterns <---------- REMOVE THESE LINES? plcm Nem_GHZ_2nd, $39A0 ; GHZ secondary patterns <---- REMOVE THESE LINES? plcm Nem_Stalk, $6B00 ; flower stalk plcm Nem_PplRock, $7A00 ; purple rock plcm Nem_Crabmeat, $8000 ; crabmeat enemy plcm Nem_Buzz, $8880 ; buzz bomber enemy Because I removed them for all instances as stated above. And then: That line gives me this build error: SONIC.ASM(5136) : Error : Symbol 'queuedmatransfer' not defined However, if I remove that line I get 0 errors, BUT instead get a build with garbled level art in every level. So what's with this QueueDMATransfer? How do I define it and why am I get garbled art? What do I really need to do in Pattern Load Cues? I followed everything as stated from start to finish. This is not rocket science so what am I missing?
You'll need to implement the DMA queue that Sonic 2/3K uses to implement what you want. There's actually a guide for it in the spindash in Sonic 1 tutorial (part 3), though I think that's targeted for Hivebrain. Shouldn't be too difficult to apply to the GitHub disassembly.
Ugh. In another example of Shadow05 butchering one of my guides, he helpfully decided to remove this little tidbit from the GitHub section:
Yes but which .asm am I editing and inputting all of that from the QueueDMATransfer guide? I can't find those labels in any file because that's probably what they're call in the Hivebrain disasm. I can't pinpoint where I'm supposed to cut/paste any of it.
I'm gonna pull my hair out. Which file do I edit? Some of these guides fail to include a simple statement of "Open ____.asm and after routine ____, paste this:" It shouldn't be expected that everyone already knows where in the 50K lines of code that "loc_D50" is located. That earlier addition of the DMA_68KtoVRAM in part 2 of the Spin Dash guide is completely obsolete since the part 3 DMA queue guide has you paste over the entire routine you just added in part 2. The only thing I need to know is which file am I editing this into that has the label ShowVDPGraphics (to paste the DMA queue after it) and loc_D50 (to add 2 lines of code as mentioned in guide part 2 to call upon Process_DMA)? I'm just doing all of this to load my level art with Kosinski.
I know I've asked this question before, but it's just that I do not know what to do anymore, Tails does not carry Sonic. Here is the code: Spoiler Code (Text): Tails_Carry_Sonic: tst.b (a2) beq.w loc_14534 cmpi.b #4,routine(a1) bcc.w loc_14466 btst #1,Status(a1) beq.w loc_1445A move.w ($FFFFF300).w,d1 cmp.w x_vel(a1),d1 bne.s loc_1445A move.w ($FFFFF400).w,d1 cmp.w y_vel(a1),d1 bne.s loc_14460 tst.b obj_control(a1) bmi.s loc_1446A andi.b #$70,d0 beq.w loc_14474 clr.b obj_control(a1) clr.b (a2) move.b #$12,1(a2) andi.w #$F00,d0 beq.w loc_14410 move.b #$3C,1(a2) loc_14410: ; CODE XREF: Tails_Carry_Sonic+4Cj btst #$A,d0 beq.s loc_1441C move.w #-$200,x_vel(a1) loc_1441C: ; CODE XREF: Tails_Carry_Sonic+5Aj btst #$B,d0 beq.s loc_14428 move.w #$200,x_vel(a1) loc_14428: ; CODE XREF: Tails_Carry_Sonic+66j move.w #-$380,y_vel(a1) bset #1,Status(a1) move.b #1,jumping(a1) move.b #$E,y_radius(a1) move.b #7,x_radius(a1) move.b #2,anim(a1) bset #2,Status(a1) bclr #4,Status(a1) rts ; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ loc_1445A: ; CODE XREF: Tails_Carry_Sonic+16j ; Tails_Carry_Sonic+22j move.w #-$100,y_vel(a1) loc_14460: ; CODE XREF: Tails_Carry_Sonic+2Cj move.b #0,jumping(a1) loc_14466: ; CODE XREF: Tails_Carry_Sonic+Cj clr.b obj_control(a1) loc_1446A: ; CODE XREF: Tails_Carry_Sonic+32j clr.b (a2) move.b #$3C,1(a2) rts ; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ loc_14474: ; CODE XREF: Tails_Carry_Sonic+38j move.w x_pos(a0),x_pos(a1) move.w y_pos(a0),y_pos(a1) addi.w #$1C,y_pos(a1) loc_14492: ; CODE XREF: Tails_Carry_Sonic+D0j andi.b #-4,render_flags(a1) andi.b #-2,Status(a1) move.b Status(a0),d0 andi.b #1,d0 or.b d0,render_flags(a1) or.b d0,Status(a1) loc_144BA: ; CODE XREF: Tails_Carry_Sonic+F8j subq.b #1,anim_frame_duration(a1) bpl.s loc_144F8 move.b #$B,anim_frame_duration(a1) moveq #0,d1 move.b anim_frame(a1),d1 addq.b #1,anim_frame(a1) move.b byte_14522(pc,d1.w),d0 cmpi.b #-1,d0 bne.s loc_144E4 move.b #0,anim_frame(a1) move.b byte_14522(pc),d0 loc_144E4: ; CODE XREF: Tails_Carry_Sonic+11Ej move.b d0,mapping_frame(a1) moveq #0,d0 move.b mapping_frame(a1),d0 move.l a2,-(sp) jsr Tails_Carry_LoadPLC movea.l (sp)+,a2 loc_144F8: ; CODE XREF: Tails_Carry_Sonic+104j move.w x_vel(a0),($FFFFB018).w move.w x_vel(a0),($FFFFF300).w move.w y_vel(a0),($FFFFB01A).w move.w y_vel(a0),($FFFFF400).w movem.l d0-a6,-(sp) lea (Maincharacter).w,a0 bsr.w Sonic_DoLevelCollision movem.l (sp)+,d0-a6 rts ; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ byte_14522: dc.b $91 ; DATA XREF: Tails_Carry_Sonic+126t dc.b $91 dc.b $90 dc.b $90 dc.b $90 dc.b $90 dc.b $90 dc.b $90 dc.b $92 dc.b $92 dc.b $92 dc.b $92 dc.b $92 dc.b $92 dc.b $91 dc.b $91 dc.b $FF dc.b 0 ; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ loc_14534: ; CODE XREF: Tails_Carry_Sonic+2j tst.b 1(a2) beq.s loc_14542 subq.b #1,1(a2) bne.w locret_1459C loc_14542: ; CODE XREF: Tails_Carry_Sonic+17Ej move.w x_pos(a1),d0 sub.w x_pos(a0),d0 addi.w #$10,d0 cmpi.w #$20,d0 bcc.w locret_1459C move.w y_pos(a1),d1 sub.w y_pos(a0),d1 subi.w #$20,d1 loc_1456C: ; CODE XREF: Tails_Carry_Sonic+1ACj cmpi.w #$10,d1 bcc.w locret_1459C tst.b obj_control(a1) bne.s locret_1459C cmpi.b #4,routine(a1) bcc.s locret_1459C tst.w (Debug_placement_mode).w bne.s locret_1459C tst.b Spindash_flag(a1) bne.s locret_1459C bsr.s sub_1459E moveq #$4A,d0 jsr (Play_Sound_2).l move.b #1,(a2) locret_1459C: ; CODE XREF: Tails_Carry_Sonic+184j ; Tails_Carry_Sonic+198j ... rts ; End of function Tails_Carry_Sonic ; ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ S U B R O U T I N E ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ sub_1459E: ; CODE XREF: ROM:00013FEAp ; ROM:000140F6p ... clr.w x_vel(a1) clr.w y_vel(a1) clr.w inertia(a1) clr.w anim(a1) move.w x_pos(a0),x_pos(a1) move.w y_pos(a0),y_pos(a1) addi.w #$1C,y_pos(a1) move.w #$2200,anim(a1) move.b #0,anim_frame_duration(a1) move.b #0,anim_frame(a1) move.b #3,obj_control(a1) bset #1,Status(a1) bclr #4,Status(a1) move.b #0,spindash_flag(a1) andi.b #-4,render_flags(a1) andi.b #-2,Status(a1) move.b Status(a0),d0 andi.b #1,d0 or.b d0,render_flags(a1) or.b d0,Status(a1) move.w x_vel(a0),($FFFFF300).w move.w x_vel(a0),x_vel(a1) move.w y_vel(a0),($FFFFF400).w move.w y_vel(a0),y_vel(a1) eori.b #2,render_flags(a1) locret_14630: ; CODE XREF: sub_1459E+84j rts ; End of function sub_1459E
Is there an extra step involved in loading the title screen menu art for Sonic 2 into SonMapEd beyond loading the mappings and art? I can see the tiles, and the mappings seem to be the right shape, but the frames just look like speckled garbage. What am I missing? Any help is appreciated. EDIT: Nevermind, I had a poke at the mapping file in hex and I get it now. It references more than one art file so I guess it would need a VRAM dump to view in SonMapEd.
No, only that you have a basic grasp of your text editor and how to locate a particular string within a file or group of files. The refactor you're attempting to do is not a particularly easy task. If you're willing to try something of that magnitude, then you are most definitely expected to stumble a few times and teach yourself along the way -- the sort of guide you describe often teaches nothing and leads to the sea of Megamix clones we had a decade ago. The wiki already too often leans towards that kind of tutorial.
I get your point Neo and you're right. I've been stumbling here and there since my hacking experience = several weeks. I understand the editor I'm using though. I've managed to get the Kosinski to work and see the difference in loading times but I'm getting GHZ with moderate amount of garbled art and the rest of the levels entirely garbled to death. I don't know what's up. It's only frustrating because I'm following a guide with the mentality/expectation that it's as simple and straightforward as it is being presented. I'll figure it out unless anyone else can offer suggestions. I guess I can't complain when countless others have had to figure this all out from scratch so... thanks everybody.
Hello! I'm making a Sonic 1 romhack and I have a question about how the game handles collision. I've been trying to find out how the game detects when Sonic hits a wall when airborne, but I can't seem to find out how (or more importantly, where) it does it. I think it has something to do with the findwall routine, but that seems to only be triggered in Sonic_Floor.asm. It would also help if someone could explain how the game detects the angle of a surface. The reason I'm trying to find out how these work is because I'm attempting to allow Sonic to run on any surface, kind of like in that cool fan-game Eggman Hates Furries. Thanks in advance! I hope I'm not asking for too much!
When airborne, it handles collision in Sonic_Floor (great label name, I know). In that routine, it checks the direction Sonic is moving at and handles collision accordingly. (Moving down checks wall and floor collision, moving up checks wall and ceiling collision, and moving left and right checks for ceiling and floor, and collision for whichever wall Sonic is going towards). Sonic_HitWall is the routine that checks for wall collision on Sonic's left side. sub_14EB4 is the same thing but for the right side. Sonic_HitFloor checks for floor collision and Sonic_DontRunOnWalls checks for ceiling collision. As for angle detection, each 16x16 block has an assigned "collision block" (as I like to call them), with each collision block having a hardcoded angle value, meaning that it's not calculated in game.
I've been busy trying to change the level title card, but I've ran into an issue, which I don't know how to fix. Here are the title card's mappings I created: Spoiler [68k]M_Card_Oval: dc.b $27 ; Oval dc.b 0, 0, 0, $68, 0 dc.b 8, 0, 0, $68, 0 dc.b $0A, 0, 0, $68, 0 dc.b $10, 0, 0, $68, 0 dc.b $18, 0, 0, $68, 0 dc.b $1A, 0, 0, $68, 0 dc.b $20, 0, 0, $68, 0 dc.b $28, 0, 0, $68, 0 dc.b $2A, 0, 0, $68, 0 dc.b $30, 0, 0, $68, 0 dc.b $38, 0, 0, $68, 0 dc.b $3A, 0, 0, $68, 0 dc.b $40, 0, 0, $68, 0 dc.b $48, 0, 0, $68, 0 dc.b $4A, 0, 0, $68, 0 dc.b $50, 0, 0, $68, 0 dc.b $58, 0, 0, $68, 0 dc.b $5A, 0, 0, $68, 0 dc.b $60, 0, 0, $68, 0 dc.b $68, 0, 0, $68, 0 dc.b $6A, 0, 0, $68, 0 dc.b $70, 0, 0, $68, 0 dc.b $78, 0, 0, $68, 0 dc.b $7A, 0, 0, $68, 0 dc.b $80, 0, 0, $68, 0 dc.b $88, 0, 0, $68, 0 dc.b $8A, 0, 0, $68, 0 dc.b 0, 1, 0, $66, $08 dc.b $10, 1, 0, $66, $08 dc.b $20, 1, 0, $66, $08 dc.b $30, 1, 0, $66, $08 dc.b $40, 1, 0, $66, $08 dc.b $50, 1, 0, $66, $08 dc.b $60, 1, 0, $66, $08 dc.b $70, 1, 0, $66, $08 dc.b $80, 1, 0, $66, $08 dc.b $90, 1, 0, $66, $08 dc.b $A0, 1, 0, $66, $08 dc.b $B0, 1, 0, $66, $08[/68k] (I know it's quite big, but I only had 3 tiles of VRAM left, so I had to constantly repeat the same tiles over and over again whilst slightly changing the tile's position every time :specialed:/>/>). Now, the issue is that not all of these tiles show up in-game. Spoiler As seen, the mappings cut off at a certain distance. I don't exactly understand what's happening here, am I running into a sprite-size limit? Edit: put the (quite large) image in a spoiler tag.
