Saxman's Sonic Boom Engine is now on GitHub: https://github.com/saxman727/sboom Please create a new branch if you plan to make modifications! I think 'tedious' would apply if someone wants to use a hex editor to change the levels. On the first post of this topic, I included a link to some level format conversion tools I wrote to port Sonic 2 levels to Sonic Boom. If MainMemory adds Sonic Boom support back into his editor, then that will allow larger zones to be created. Then, the only thing to really do at that point is update my tools to be able to merge physical and visual files since there's no level editor yet that supports this concept. You should use it for the hacking contest next year! I would like to see how many people will pick it up.
I like what I'm seeing! This looks like a really solid base for Sonic 2 modifications, taking a serious chunk of the busywork out of the whole process and adding really cool stuff like the new level layout format on top of that. I'm very happy to see Knuckles ported in by default, I've done this myself but it's truly mind numbing work, not to mention error-prone if you're anything like me. So many hours lost, so much rage at compile errors. I hardly have the time anymore to hack around with Sonic games but I still want to play with this.
Saxman which SH2 is doing the Kos decompression? If it's master then I may try to add PWM out of boredom to see how well it will work. Also curious question, What method did you use to get your DMA working? I use the RV bit with a RAM Run code to get my DMA working for the Player art which works well.
Development on the next major version is underway. Current plans for the next release: * Merge Sonic 1 into Saxman's Sonic Boom to create one consolidated code base from which to build Sonic 1 and 2 ROMs and allow features from each game to be mixed and matched via configurations in the "constants.asm" file. * Enhanced sound driver to support more sounds and add PWM support (I'm looking at you Varion, that is if you want to help with this). * Import the Sonic 3 objects manager for improved performance * Update the code to improve labeling and data organization (perhaps partially based on the current GitHub efforts) Those are my priorities. But I'm curious what you all would like to see in the next release. What are some things you think Saxman's Sonic Boom really needs that it doesn't currently offer?
I would suggest anything related to gameplay performance first, then anything to improve the sound driver. Clownacy is currently doing a universal SOnic 2 Clone Driver, could it be a good candidate for inclusion?
Eh, I'd rather see an improved S2 driver. I've been using one in my S2 hack for a while. The changes you can make are minimal, but they're nice. Things like removing the 'nop's from the jump tables, removing unused junk, fixing 'bugs', reducing the size of some things, even dynamic music, SFX and DAC bank selection. The DAC driver has a really obvious optimisation you can make to the DPCM stream loop, which makes the playback speed a bit better, consistent (the two halves of the loop use the same cycles if you use a 'nop' after the optimisation), and requires all samples' "pitch" values be increased by 1, which means you should be able to get away with higher quality samples, but I don't know if the maximum speed is beyond what the YM2612 can read. Maybe you can even merge a Mega PCM feature or two in there. Besides, my driver still isn't 100% accurate yet. It looks like S2's driver contains some cryptic fixes for bugs that originate in S1's driver, and I still haven't found them. By the way, I have a suggestion: There's the old mapping error where Knuckles moves forward when he looks up.
I've always been curious about that. When I look at Knuckles in SonMapEd that sprite doesn't appear to be misaligned at all, I never understood what causes it to shift forward that one pixel in game. Easy to fix in the mappings, but I wonder if that's actually more of a workaround than a proper fix. It just never felt right to me.
Given if the S2 Sound driver's disassembly works like the S3K one in terms of compiling I can implement the PWM into the stock Sonic 2 driver and remove DAC. Though the S3K driver does allow for more customizations currently thanks to Flamewing. We restored FM6 not that long ago in that driver and I implemented PWM into my version [along side of DAC actually but that's a whole different story] Anyways it's relatively easy to setup once the Z80 driver is fully setup. just give me a shout on skype where I'm usually at and I can assist.
DO you think its possible technically to create something hybrid if we don't plan on using the 32x? DAC playing through 32x or FM6 depending on what we plan to build?
I'm curious too -- of the new features listed on the first post, what ones are your favorite? Let me know! Your wish is my command. Fixed. It always bothered me when I was younger My preferred design approach would be to "add" PWM rather than "replace" DAC. I like backward compatibility. I will be in touch with you to try and figure out what I need to do this.
Actually, can a best-of both worlds approach would work? Is that even feasible? Using FM6 when no 32X is present, but switch to PWM if it is? Theoricaly it seems ok, but can the Z80 driver handle that?
Any combination is possible with little to no difficulty. I suppose what you would define as "difficult" would depend on ones knowledge, but the Z80 will handle whatever it is programmed to handle provided the programmer has brains.
I'm making a good bit of headway with moving Sonic 1 over to the Sonic Boom base. GHZ is about 90% there. Here are a couple screenshots: Sonic 1 style HUD. Here, we play with Sonic and Tails: Sonic 2 style HUD. Because it's Sonic Boom, we can easily put Knuckles in Sonic 1: The first release of Saxman's Sonic Boom engine was to fix a lot of bugs in Sonic 2 and enhance the underlying engine while still staying true to what made Sonic 2... well... Sonic 2! The main point of the next release is to give hackers all assets from Sonic 1 and 2 without having to "port" anything. Using a series of configuration settings, you can decide what assets to use from each game. Mix and match what you want. Think of it as a mega-interoperable code base for Sonic 1, Sonic 2, Sonic 1+2, Sonic 1 with a Little 2, Sonic 2 with a Dash of 1, etc. This is also a good opportunity to merge common code between the two games. And there's a LOT of it. Below is an example of Obj95 (the Sol badnik from HTZ). I merged it with Orbinaut, because the two are nearly the same object. For Sonic 1, it's Orbinaut. For Sonic 2, it's Sol. For complex, you control if it's Sol or Orbinaut by using the MSB of the subtype. And it works beautifully! KEEP IN MIND: One of my goals for the next release is to improve labeling and the overall look of the code. The below code is not exempt from that effort, so be mindful that this will be improved. Anyway, here it is in its current form: Code (Text): ; ---------------------------------------------------------------------------- ; Object 95 - Sol (fireball-throwing orbit badnik) from HTZ ; Orbinaut enemy (LZ, SLZ, SBZ) ; ---------------------------------------------------------------------------- ; Sprite_370FE: Obj95: moveq #0,d0 move.b routine(a0),d0 move.w Orb_Index(pc,d0.w),d1 jmp Orb_Index(pc,d1.w) ; =========================================================================== Orb_Index: dc.w Orb_Main-Orb_Index dc.w Orb_ChkSonic-Orb_Index; 1 dc.w Orb_Display-Orb_Index; 2 dc.w Orb_MoveOrb-Orb_Index; 3 dc.w Orb_ChkDel2-Orb_Index; 4 orb_parent: = $3C ; address of parent object ; =========================================================================== Orb_Main: if INCLUDE_SONIC_1_LEVELS == TRUE if INCLUDE_SONIC_2_LEVELS == TRUE btst.b #7,subtype(a0) beq.s ++ endif move.l #(ROM_Start+Map_Orb),mappings(a0) cmpi.b #ZONE_ID_LZ,(Current_Zone).w bne.s + move.w #$530,art_tile(a0) ; LZ specific code bra.s +++ + move.w #$429,art_tile(a0) ; SLZ specific code if INCLUDE_SONIC_2_LEVELS == TRUE bra.s ++ endif + endif if INCLUDE_SONIC_2_LEVELS == TRUE move.l #(ROM_Start+Obj95_MapUnc_372E6),mappings(a0) move.w #0,art_tile(a0) ; HTZ specific code endif + bsr.w JmpTo64_Adjust2PArtPointer ori.b #4,render_flags(a0) move.b #4,priority(a0) move.b #$B,collision_flags(a0) move.b #$C,width_pixels(a0) if INCLUDE_SONIC_2_LEVELS == TRUE if INCLUDE_SONIC_1_LEVELS == TRUE btst.b #7,subtype(a0) bne.s + endif move.w #-$40,x_vel(a0) endif + moveq #0,d2 lea objoff_37(a0),a2 movea.l a2,a3 addq.w #1,a2 moveq #3,d1 Orb_makesatellites: bsr.w JmpTo25_SingleObjLoad2 bne.s Orb_fail addq.b #1,(a3) move.w a1,d5 subi.w #$B000,d5 lsr.w #6,d5 andi.w #$7F,d5 move.b d5,(a2)+ move.b 0(a0),0(a1) ; load obj95 move.b #6,routine(a1) ; use Orb_MoveOrb routine move.l mappings(a0),mappings(a1) move.w art_tile(a0),art_tile(a1) ori.b #4,render_flags(a1) move.b #4,priority(a1) move.b #8,width_pixels(a1) move.b #3,mapping_frame(a1) move.b #$98,collision_flags(a1) move.b d2,angle(a1) if INCLUDE_SONIC_1_LEVELS == TRUE if INCLUDE_SONIC_2_LEVELS == TRUE move.b subtype(a0),subtype(a1) endif endif addi.b #$40,d2 move.l a0,objoff_3C(a1) dbf d1,Orb_makesatellites ; repeat sequence 3 more times Orb_fail: moveq #1,d0 btst #0,status(a0) ; is orbinaut facing left? beq.s Orb_noflip ; if not, branch neg.w d0 Orb_noflip: move.b d0,objoff_36(a0) move.b subtype(a0),routine(a0) ; if type is 02, skip Orb_ChkSonic andi.b #$E,routine(a0) addq.b #2,routine(a0) move.w #-$40,x_vel(a0) ; move orbinaut to the left btst #0,status(a0) ; is orbinaut facing left? beq.s Orb_noflip2 ; if not, branch neg.w x_vel(a0) ; move orbinaut to the right Orb_noflip2: rts ; =========================================================================== Orb_ChkSonic: ; Routine 2 move.w (MainCharacter+x_pos).w,d0 sub.w x_pos(a0),d0 ; is Sonic to the right of the orbinaut? bcc.s Orb_isright ; if yes, branch neg.w d0 Orb_isright: cmpi.w #$A0,d0 ; is Sonic within $A0 pixels of orbinaut? bcc.s Orb_animate ; if not, branch move.w (MainCharacter+y_pos).w,d0 sub.w y_pos(a0),d0 ; is Sonic above the orbinaut? bcc.s Orb_isabove ; if yes, branch neg.w d0 Orb_isabove: cmpi.w #$50,d0 bcc.s Orb_animate tst.w (Debug_placement_mode).w bne.s Orb_animate move.b #1,anim(a0) Orb_animate: if INCLUDE_SONIC_2_LEVELS == TRUE if INCLUDE_SONIC_1_LEVELS == TRUE btst.b #7,subtype(a0) bne.s + endif bsr.w JmpTo26_ObjectMove lea (ROM_Start+Ani_Orb).l,a1 bsr.w JmpTo25_AnimateSprite andi.b #3,mapping_frame(a0) bra.w JmpTo39_MarkObjGone endif + if INCLUDE_SONIC_1_LEVELS == TRUE lea (ROM_Start+Ani_Orb).l,a1 bsr.w JmpTo25_AnimateSprite bra.w Orb_ChkDel endif ; =========================================================================== Orb_Display: ; Routine 4 bsr.w JmpTo26_ObjectMove if INCLUDE_SONIC_2_LEVELS == TRUE if INCLUDE_SONIC_1_LEVELS == TRUE btst.b #7,subtype(a0) bne.s + endif lea (ROM_Start+off_372E0).l,a1 bsr.w JmpTo25_AnimateSprite andi.b #3,mapping_frame(a0) bra.w JmpTo39_MarkObjGone + endif if INCLUDE_SONIC_1_LEVELS == TRUE Orb_ChkDel: move.w x_pos(a0),d0 andi.w #$FF80,d0 sub.w (Camera_X_pos_coarse).w,d0 cmpi.w #OBJECT_X_SCOPE,d0 bhi.w Orb_chkgone jmp DisplaySprite Orb_chkgone: lea (Object_Respawn_Table).w,a2 moveq #0,d0 move.b respawn_index(a0),d0 beq.s loc_s1_11E34 bclr #7,2(a2,d0.w) loc_s1_11E34: lea $37(a0),a2 moveq #0,d2 move.b (a2)+,d2 subq.w #1,d2 bcs.s Orb_Delete loc_s1_11E40: moveq #0,d0 move.b (a2)+,d0 lsl.w #6,d0 addi.l #Object_RAM&$FFFFFF,d0 movea.l d0,a1 jsr DeleteObject2 dbf d2,loc_s1_11E40 Orb_Delete: jmp DeleteObject endif ;if INCLUDE_SONIC_1_LEVELS == TRUE ; =========================================================================== Orb_MoveOrb: ; Routine 6 if INCLUDE_SONIC_2_LEVELS == TRUE if INCLUDE_SONIC_1_LEVELS btst.b #7,subtype(a0) bne.s + endif lea (ROM_Start+off_372E0).l,a1 bsr.w JmpTo25_AnimateSprite endif + movea.l orb_parent(a0),a1 ; a1=object cmpi.b #$95,0(a1) bne.w JmpTo65_DeleteObject cmpi.b #2,mapping_frame(a1) bne.s Orb_circle cmpi.b #$40,angle(a0) bne.s Orb_circle addq.b #2,routine(a0) if INCLUDE_SONIC_2_LEVELS == TRUE if INCLUDE_SONIC_1_LEVELS == TRUE btst.b #7,subtype(a0) bne.s + endif move.b #0,anim(a0) endif + subq.b #1,objoff_37(a1) bne.s Orb_fire addq.b #2,routine(a1) Orb_fire: move.w #-$200,x_vel(a0) btst #0,status(a1) beq.s Orb_noflip3 neg.w x_vel(a0) Orb_noflip3 bra.w JmpTo45_DisplaySprite ; =========================================================================== Orb_circle: move.b angle(a0),d0 jsr (ROM_Start+CalcSine).l asr.w #4,d1 add.w x_pos(a1),d1 move.w d1,x_pos(a0) asr.w #4,d0 add.w y_pos(a1),d0 move.w d0,y_pos(a0) move.b objoff_36(a1),d0 add.b d0,angle(a0) bra.w JmpTo45_DisplaySprite ; =========================================================================== Orb_ChkDel2: bsr.w JmpTo26_ObjectMove tst.b render_flags(a0) bpl.w JmpTo65_DeleteObject if INCLUDE_SONIC_2_LEVELS == TRUE if INCLUDE_SONIC_1_LEVELS == TRUE btst.b #7,subtype(a0) bne.s + endif lea (ROM_Start+off_372E0).l,a1 bsr.w JmpTo25_AnimateSprite endif + bra.w JmpTo45_DisplaySprite ; =========================================================================== ; animation script Ani_Orb: dc.w Ani_Orb_normal-Ani_Orb dc.w Ani_Orb_angry-Ani_Orb; 1 Ani_Orb_normal: dc.b $F, 0,$FF Ani_Orb_angry: dc.b $F, 1, 2,$FE, 1 even if INCLUDE_SONIC_2_LEVELS == TRUE ; animation script off_372E0: dc.w byte_372E2-off_372E0 byte_372E2: dc.b 5, 3, 4,$FF even endif ; ---------------------------------------------------------------------------- ; sprite mappings ; ---------------------------------------------------------------------------- if INCLUDE_SONIC_1_LEVELS == TRUE Map_Orb: BINCLUDE "mappings/sprite/obj95_1.bin" even endif if INCLUDE_SONIC_2_LEVELS == TRUE Obj95_MapUnc_372E6: BINCLUDE "mappings/sprite/obj95_2.bin" endif
I had been pretty much away for about 2 months, which put my project on ice. But now I am back and I come back to this? I'm excited. I had restarted my hack from scratch recently using the 2007 disassembly and was in the process of doing a few things already done in your Sonic Boom engine. So naturally I've decided to scrap what little I had done and move over to this engine (of course improving on some small things and fixing more bugs as I go). I fully support this project and any further work you will do with it. Question though, even though your plans for the next release is to merge Sonic 1 and 2 into the same source/engine... might there be plans down the road sometime to do the same with Sonic 3/ Sonic & Knuckles?
Instead of outright denying the ability to place objects in debug mode while dead, how about adding a different workaround that allows the placement, without the crashing? Also, some other REV00 goodies, like Obj74 and Obj66 being visible in debug placement mode? Also, what of doing what REV02 did, and removing all of the JmpTos? Speaking of, where'd that line about 'adda.w invincibility_time(a6),a1' come from? That's not there in REV02 or KiS2.
I meant to comment on this earlier. As it has been said, anything is technically possible. My plan would be to have the extra values and such available only in the 32X port. So it would be one code base with compiler checks to include/exclude certain things, much like I'm currently working on with the Sonic 1 and Sonic 2 stuff. Great! Any bugs or problems you have specific to Sonic Boom, let me know. I have given some thought to Sonic 3K. I'm open to the idea. I have also thought about Sonic CD and how it might be interesting to support it on the Genesis. Or, maybe allow Sonic Boom to compile for the Sega CD and do a more natural port of Sonic CD that way. There's a couple avenues to look at. But for certain, I don't want to stop after Sonic 1. Any preferences on this front? That's interesting. I may just put that debug placement solution in the next major release, or maybe even slip it in a patch release for v1.00. And yes, I definitely gave consideration to see the invisible objects (Obj03 is another good one). I wasn't sure quite how to do it though, so it got pushed to the back burner. I'd still like to do that though. As for the line you referenced, I think what I meant to write is Rev01 rather than Rev02. In my head I know it's the second release of Sonic 2, and so I have a habbit of immediately thinking 'revision 02', even though that's obviously wrong. If I remember correctly, Knuckles in Sonic 2 changed that line, and I couldn't understand why. I went with speculative reasoning that if it was changed, it was probably to fix something. But because I wasn't 100% sure, I left the original line there in the comment. If you or anyone else knows what the purpose of the change might be, I'm interested in hearing about it.
Personally, I'd stick with one at a time - make this as good as you can first before going on to something else. Unless you're going to be able to cram S1/2/3K in one ROM with this, then I'd go for SMD support of Sonic CD first. It seems to be the natural next step.
Saxman, this is really awesome and I love every aspect of this project from the concept to the execution. If my coding skills were up to snuff, I'd have tried the same thing; a unified, polished/bug-fixed yet faithful version of the disassemblies, for community use. The thing I like most about it is the attempt to establish some kind of base standard so that hackers can focus on what they want to/are good at without having to worry about handling the commonly expected bug-fix/extra feature checklist. It's a goddamn waste of time to redo what's already been done but better, so why not just have those expected assembly changes be accessible by default? It probably has a lot to do with how the different companies themselves handle their properties, but I've always preferred the creative culture on the Doom side of things than the Sonic side of things. People in the Doom community are by default very friendly and willing to lend a hand up so that every person can shine in their area of skill. It's a communal effort, those that have skill in some areas help those that are stronger in others, and the result is a collective higher quality in projects. Here, though, the default seems to be a far more private, secretive "do it yourself noob" attitude, with attempted justification being some form of disdain for "plebians" doing "distasteful" things with advanced code features as if that was some kind of problem to express one's self creatively no matter the quality. No harm in sharing your code as long as its users give due credit. I hope that this project shifts that attitude more toward an open-source, communal philosophy wherever that more 'elitist' mentality may exist. I haven't seen a whole lot of it at all lately, but I'm not really around here much these days. We're all 'thieves' anyway by having these disassemblies. People here help each other out anyway, I just wish that selfish "my code!" mentality didn't exist at all even in the past, given how hypocritical it is. Yes, CD seems a better next step than 3K given that it is mostly a souped-up S1, whereas 3K made fundamental changes to many, many things. I personally consider Sonic 3 Complete the definitive version of 3K, and I know there are reservations about sharing the source to respect the vast number of external contributors the project has seen, playing it safe to ensure that no one's contributions are shared without express permission. If 3K support is ever added to Boom, I think it should be based on S3C if negotiations can be worked out.