Ladies and gentlemen, I once again require assistance; I have downloaded the AMPS sound driver, but...I have not discovered any source displaying information on how to install it to a Sonic 3 & Knuckles disassembly. How would one achieve this? I greatly appreciate any and all aid in this matter.
Unfortunately, the current release is not available for any disassemblies that use AS. The Sonic 2 and Sonic 3K disassemblies happen to use this assembler, so they, for now, are not supported. This is because of the difficulty of porting the entire sound driver to AS; It is very complex and uses a few hacks to "extend" the feature-set of the ASM68K assembler. I am not sure how the macro code required would be written in AS (and as far as I know, nobody really is), it will take a fair long time porting the sound driver over. The amount of code required to be ported will be time consuming. Therefore, it will take a bit of time to get ported over, but I have plans to do so for the next release. Because of many other complications, it is possible that while the Github page may get updated with an AS version, but take a while to create an actual release. As it stands currently, there is not much you can do beyond porting it to AS yourself or waiting patiently. I plan to release tutorials for Sonic 2 and 3K Git disassemblies, showcasing how the driver can be ported over.
Very well, I give you my thanks regardless. Besides, the project I had in mind for Sonic 3 is still on paper, and I've returned to my Sonic 2 hack for the time being. I switched to the Sonic 3 sound driver for that particular hack, and so far it seems to work just fine.
Hello, I have a feature that I would like to implement to my hack, but I don't know how. I want to make the "Act 1, 2, 3" text in Sonic 1 get its color from palette line two, meaning that this specific palette line should load before the fade in happens (I don't mind it fading in with the rest as long as it's loaded before the fade in). Does anybody know how, or at least point me in the right direction?
Code (Text): byte_CB26: dc.b 2 ; ACT 1 dc.b 4, $C, 0, $53, $EC dc.b $F4, 2, 0, $57, $C byte_CB31: dc.b 2 ; ACT 2 dc.b 4, $C, 0, $53, $EC dc.b $F4, 6, 0, $5A, 8 byte_CB3C: dc.b 2 ; ACT 3 dc.b 4, $C, 0, $53, $EC dc.b $F4, 6, 0, $60, 8 Each one of these represents an act, all of them have two sprites, the first sprite is the "ACT" text, the second sprite is the act number art. Change the third byte of the sprite piece from 0 to $20 to change the palette line. Be warned, it will appear as black until the palette fades in: Code (Text): byte_CB26: dc.b 2 ; ACT 1 dc.b 4, $C, $20, $53, $EC dc.b $F4, 2, $20, $57, $C byte_CB31: dc.b 2 ; ACT 2 dc.b 4, $C, $20, $53, $EC dc.b $F4, 6, $20, $5A, 8 byte_CB3C: dc.b 2 ; ACT 3 dc.b 4, $C, $20, $53, $EC dc.b $F4, 6, $20, $60, 8
Seems like I wasn’t specific enough with my previous knowledge or with what I need. I need the 2nd palette line to be loaded so the text actually appears yellow when taking from the ring palette, instead of black. I’ve seen a ROM hack do that, so I know it’s possible I just need to at least know what code to edit.
Ahhh, I see now. Are... are you sure you want to do that? A concern I will have though, many objects and certain level graphics will use the second palette line, so you might find stuff like "rings" will just "appear" on-screen during the title card idling, or the GHZ flowers will suddenly pop in before the fade in starts. I haven't checked all of the default levels, but I would assume you're making brand new levels or different levels which may avoid this issue entirely. Well if you do, the palette is usually loaded after the level art/chunks/etc in the main load block subroutine, it's loaded during the title card idling on-screen, so this needs to be rectified. Goto "MainLoadBlockLoad:", and delete (or comment out) the following lines: Code (Text): move.w (a2)+,d0 move.w (a2),d0 andi.w #$FF,d0 cmpi.w #$103,($FFFFFE10).w ; is level SBZ3 (LZ4) ? bne.s MLB_ChkSBZPal ; if not, branch moveq #$C,d0 ; use SB3 pallet MLB_ChkSBZPal: cmpi.w #$501,($FFFFFE10).w ; is level SBZ2? beq.s MLB_UsePal0E ; if yes, branch cmpi.w #$502,($FFFFFE10).w ; is level FZ? bne.s MLB_NormalPal ; if not, branch MLB_UsePal0E: moveq #$E,d0 ; use SBZ2/FZ pallet MLB_NormalPal: bsr.w PalLoad1 ; load pallet (based on d0) This'll stop the main load block loading the palette. Now go to "Level_DelayLoop:", find the line: Code (Text): move.w #$202F,($FFFFF626).w Change it to: Code (Text): move.w #$401F,($FFFFF626).w This will ensure only palette lines 3 and 4 fade in, and line 2 is ignored. Finally, goto "Level_LoadPal:", after the line "bsr.w PalLoad2", put in the following: Code (Text): moveq #$00,d0 ; clear d0 move.b ($FFFFFE10).w,d0 ; load Zone ID lsl.w #$04,d0 ; multiply by x10 (size of entry in table) lea (MainLoadBlocks+$0F).l,a0 ; load main load block list (+palette ID position) move.b (a0,d0.w),d0 ; load correct palette ID cmpi.w #$0103,($FFFFFE10).w ; is level SBZ3 (LZ4)? bne.s MLB_ChkSBZPal ; if not, branch moveq #$0C,d0 ; use SB3 pallet MLB_ChkSBZPal: cmpi.w #$0501,($FFFFFE10).w ; is level SBZ2? beq.s MLB_UsePal0E ; if so, branch cmpi.w #$0502,($FFFFFE10).w ; is level FZ? bne.s MLB_NormalPal ; if not, branch MLB_UsePal0E: moveq #$0E,d0 ; use SBZ2/FZ pallet MLB_NormalPal: bsr.w PalLoad1 ; load pallet (based on d0) lea ($FFFFFB20).w,a1 ; load current palette (second palette line) lea $80(a1),a0 ; load source palette moveq #($20/$04)-1,d1 ; size of palette line Level_ForcePal: move.l (a0)+,(a1)+ ; copy colours over from source to current dbf d1,Level_ForcePal ; repeat until entire line is copied over This will ensure the correct palette is loaded before the title cards come on-screen, it'll load all three lines into the source palette, and then copy the second line over to the currently displaying palette. Lines 1 and 2 will be visible, lines 3 and 4 will be ready for fading in.
Thank you! It worked EDIT: I tested it and it seems like Palette Line 2 doesn’t load at all underwater. Any fixes?
Ah right, forgot about the water; goto "Level_ChkWaterPal:", and delete (comment out) the following: Code (Text): cmpi.b #1,($FFFFFE10).w ; is level LZ/SBZ3? bne.s Level_Delay ; if not, branch moveq #$B,d0 ; pallet $0B (LZ underwater) cmpi.b #3,($FFFFFE11).w ; is level SBZ3? bne.s Level_WaterPal2 ; if not, branch moveq #$D,d0 ; pallet $0D (SBZ3 underwater) Level_WaterPal2: bsr.w PalLoad4_Water Level_Delay: Then goto "Level_WaterPal:", and below "bsr.w PalLoad3_Water", put the following in: Code (Text): cmpi.b #1,($FFFFFE10).w ; is level LZ/SBZ3? bne.s Level_Delay ; if not, branch moveq #$B,d0 ; pallet $0B (LZ underwater) cmpi.b #3,($FFFFFE11).w ; is level SBZ3? bne.s Level_WaterPal2 ; if not, branch moveq #$D,d0 ; pallet $0D (SBZ3 underwater) Level_WaterPal2: bsr.w PalLoad4_Water Level_Delay: lea ($FFFFFA20).w,a0 ; load water destination palette line 2 lea $80(a0),a1 ; load water current palette line 2 moveq #($20/$04)-1,d1 ; size of palette line to transfer Level_ForceWater: move.l (a0)+,(a1)+ ; copy colours over to current palette dbf d1,Level_ForceWater ; repeat for all colours in the line
I did get this answered on discord, but I'm hoping for a more detailed answer here. There's a limit to how much unique art you can have in a level. What I want to know is which of the games typically has the most vram space available for it without pulling shenanigans to find more? And which of the games requires the least shenanigans for the same pursuit?
As far as I know, for all of the classic games, they tend to use a lot of VRAM during levels. I dunno which of them uses the most space, so someone else can answer that if they want. However, here are some things you can do. This should help answer your last question, assuming you are just looking to add an extra object or something, and nothing overly complex. Starting with the obvious: Removing unused art easily helps out with saving some VRAM. Sonic 1 especially has quite a number of unused tiles, especially in Labyrinth Zone. Optimizing tile usage in the level art and object sprites, too, if possible. I'd imagine Sonic 1 is the most guilty when it comes to unoptimized usage of tiles (mainly duplicate tiles and sprite pieces). You can rearrange where things get loaded to better suit your needs. In Sonic 1's case, right out of the box can the checkpoint art be relocated to $D800. Sonic 1 and 2 loads all of the shield art and invincibility stars art at once into VRAM. Sonic 3K optimizes this by only loading the appropriate shield art that is used when the shield is created. This can be further optimized by using DPLCs so that only the frame that is displayed has its art loaded into VRAM. If you want this for Sonic 1, you'll want Sonic 2/3K's DMA queue system ported. Sonic 2 uses the life icon art from the HUD, while Sonic 1 has a copy of the icon along with the monitor art. You can easily save 4 tiles by applying the Sonic 2 method onto Sonic 1. Sonic 2 also makes it so the spindash dust, water splash, and skid dust are within the same art, at the same VRAM location. It also uses that same space for the drowning countdown numbers, hence why the object is disabled when Sonic is drowning. If you have the spindash in Sonic 1, you may want to consider this. All in all, you'd have to do some shenanigans to free up some VRAM, no matter the game. However, Sonic 1 by far only really requires the simplest ones. You can just shift a couple things around, delete unused shit, and maybe optimize some tile usage here and there, and you can get a pretty healthy amount of VRAM freed up, and you wouldn't need to resort to having to rework how VRAM is handled. Sonic 2 I'd imagine would still be rather simple to optimize, but Sonic 3K already pulls quite a number of shenanigans.
Its still very possible to save tons of VRAM in Sonic 3 & Knuckles by doing a lot of shenanigans. In Sonic 3 & Knuckles, with clever tile optimization and quite a few dirty tricks, we were able to get both players to have fully working shields and few free tiles for different modes, and of course the pause screen. A few minor details had to be removed, such as the point (really who even pays attention to those), animals (this may be a bigger worry, but nobody has noticed yet), and very particular object in CNZ that used DPLC's and multiple slots to load its complex art. I think we're now only limited to 1 of them on screen at once, which is fine since the level never had any more, but its possible to load glitched version of this badnik if you do very specific things.
Novedicus mentioned the head icon being in VRAM twice, but I was more curious as to whether or not they were actually identical. Turns out no! There are a few pixels different on the spines, top is the Monitor icon, bottom is the HUD icon: I think it would be a cool idea to go back on old proto shots to see if any of them have the HUD icon change at any point. Never know, they could've been identical, and the HUD got updated but the monitors did not. We would then have a hard copy of a proto icon right under our noses.
Thanks for this. Adding objects is definitely on the docket, but it was new foreground art that prompted these questions. Neo Green Hill in Sonic Advance has sand, wooden bridges, standard green hill-esque terrain, roadways, and even a steel bridge. That's a lot of terrain types, and a lot of unique tiles that I doubt would all fit into Genesis vram. Not without shenanigans! Nonetheless, that's the detail I was looking for. Thanks to all who replied.
Well, the bridge only shows up at the end of act 2, so you could write up a level event that loads the bridge art over art that isn't necessary anymore once you cross a certain X boundary. Plenty of levels in Sonic 3 do this, such as AIZ2, ICZ1, LBZ2.
Yea I was indeed thinking that. Could do that for basically everything really, now that I think about it.
Note that you would have to add ways to prevent going back, but I guess you have already took that on account.