Help Help porting Tails to Sonic 1

Generally, this is what you'd need to do to get Tails ported in successfully:

• Currently, I do not know the details of whether or not this is imperative, per se, but generally it's beneficial to get the DMA queue from Sonic 2 ported in, will save you a lot of hassle. There's a section in part 3 of the spindash guide that shows you how to implement it in the old 2005 Hivebrain disassembly like it does with the spindash dust, but, again, it shouldn't be difficult to implement into the GitHub disassembly. Sonic 1 uses a buffer in RAM to load the player sprite graphics into, which then gets copied into VRAM, but for this kind of task, sticking with that will probably most likely be a hindrance.
  
• Copy over Obj02 (Tails) and Obj05 (Tails' Tails) and fix up any labels and constants that are incompatible. You can generally figure them out by following along the Sonic object and comparing it to Tails' object code. In fact, it might be a good idea to try to implement the differences in code into the Sonic object (or a copy of it) as you follow along. The GitHub disassembly should actually have the Sonic 2 object variable/SST constants defined. Sonic 1 doesn't use "Adjust2PArtPointer", so you can delete all calls to that. There's also no "status_secondary" in Sonic 1, either. The flags used in Sonic 2's "status_secondary" bitfield are their own separate RAM addresses in Sonic 1 (v_shield, v_invinc, v_shoes, and f_jumponly).
  
• If you are not using Project Two Eight, then the references to top_solid_bit and lrb_solid_bit aren't needed. You will need to call Sonic_Loops like the Sonic's object does, instead. Otherwise, if you ARE using Project Two Eight, you will need to change them to be direct RAM addresses instead, as that's what Project Two Eight does. You can see how they are set in the Sonic object.
  
• For the spindash dust, copy Obj08 over as well. The spindash guide for Sonic 1 does go over this for the old 2005 Hivebrain disassembly, but it shouldn't be too difficult to implement into the GitHub disassembly.
• You're most likely gonna run into an issue on where to load Tails' tails graphics into VRAM. This can be worked around, though. What I personally recommend is that you optimize the shields and invincibility stars in a way that it only one of their graphics at a time. You can easily do this with the DMA queue ported by removing the Nemesis graphics entries from the PLCs, and decompressing them, and then calling QueueDMATransfer for the appropriate graphics when a shield or invincibility stars are loaded. You'll also want to load the graphics into the same VRAM location. This way, you'll make room in that area and you can load Tails' tails graphics into there.
• Palette wise, that's probably gonna be the trickiest thing to overcome. In Sonic 2, it does away with the darkest red and uses 2 shades of orange. The HUD gets moved to line 1 instead of 0 and uses the red from line 0 when flashing. In Sonic 1, many objects use Sonic's palette and use that darkest red. With some work, you could get them to not without them looking like shit, but it's definitely going to be a tedious effort. There's a bunch of other things you can do with the graphics, but ultimately it's up to you on what you wanna do with them to get Tails' palette properly implemented.
  
• Of course, mappings and DPLCs also need to be converted to the Sonic 1 format. That can easily be done in SonMapEd, Flex 2, or MappingsConverter.

Hope this helps give you a good start.

 

What about porting Knuckles?

 

A lot of it is the same process, really, though you don't need to worry about having Tails' Tails to deal with. However, one thing that does come to mind is the possibility of a sprite frame taking up too much space than what's allocated for player sprite graphics in VRAM, causing the points graphics to be overridden (people have run into this in the past with porting Sonic 2 or 3K's sprites over). Though, with the DMA queue and shields using uncompressed art, you could just move the points graphics over to the new free space. One major thing though, would be the gliding and climbing stuff, as that uses a whole separate collision detection routine. It shouldn't be TOO much trouble to make it compatible with Sonic 1, though. Should be easier to port from Sonic 2 than from Sonic 3K, too.

Palette wise, it might be a bit of a bigger issue, depending on how you wanna go about it. You can do it the old Stealth way and just use the stock reds in Sonic's palette, or you can try to fit in Knuckles' actual palette and fix up the art and other palettes around it.

 

Thanks. I needed the Knuckles port so I can make a Tikal in Sonic 1 hack since the old Tikal in Sonic 1 hack has level changes and stuff.

 

Could you elaborate on what you mean by "broken and garbled up"?

 

You converted the DPLCs to Sonic 1's format, right? Otherwise, I'm not too sure on what it could be. Would help to post screenshots and be as descriptive as you can.

 

Actually, you can use a THREE colors for knux, but, after that- you need redraw ALL Knuckles graphics... with this- you can recolour also few blue colours for Knuckles' shoes, and as result- you had a 3 (or 2... anyway) blue colours. You'll use that for Eggman, badniks, other things...
I make it with palette limitations (without shoes colours) when I was port Knuckles in CD. I hope, it was useful

 

Just wanna add that if you wanna easily convert tiles to use a different palette, there's this tool called Palette Converter that has that feature.