Sonic 3K Object and Ring Managers in Sonic 1

I was planning on doing a tutorial on how to add this stuff, but I decided that it would take too long and I already have other stuff I need to do, so here's a disassembly. If you want to add these features to your hack, just use a program such as ExamDiff to compare the sonic1.asm here with one from the original Hivebrain disassembly and apply the changes to your own hack.

What it is

• Sonic 3 & Knuckles' object manager differs in that an object only spawns if the camera is close enough to it in both the x and y direction, rather than just the x direction like in Sonic 1 and 2. This keeps objects too far above or below Sonic from having their code run, which reduces processing and leads to less slowdown. Additionally, every object's status (destroyed or not) is saved rather than just specified ones. Instead you can specify if an object won't take the camera's y position into account for certain objects. This is useful for tall objects or objects that interact with objects far above or below them (LZ1's shortcut platform, for example).

• Rings are simple objects that require far less RAM and processing power than most objects would, and so it is more efficient to create a separate routine to load and run them than it would be to load them using the regular object loading routine. Sonic 2 added the ring manager, but Sonic 3K simplified it by treating each ring as its own object, rather than putting them in groups. This allows ring data to be read from the ROM rather than expanded it using RAM, so less RAM is used.

• When adding Sonic 3K's object manager to Sonic 1, adding a ring manager is required because Sonic 1's ring object won't save its status properly, resulting in rings respawning after leaving the screen.

Requirements

• $300 consecutive bytes free for the object respawn table (note: these will be used instead of $FC00 to $FCFF so, if you reorder your RAM addresses, you only need to find $200 free bytes). This can be done by:
  • Using a Z80 sound driver -Frees up $F000 to $F5BF (F5C0 to $F5FF are already free too)
  • Using uncompressed chunks -Frees up $0000 to $A3FF
  • Using 128 by 128 chunks -Frees up $8000 to $A3FF
• Word-sized free entry in the SST. This will be used instead of $23, so you just need to find one free one and reorder the SST to put them together. This can be done by:
  • Using RedHotSonic’s guide for Sonic 2. Both steps are applicable to Sonic 1.
• 4 bytes free for Camera_X_pos_last and Camera_Y_pos_last
• $1F0 consecutive bytes free for ring manager
• $10 bytes free for various ring manager-related RAM addresses

What is changed

• Sonic 3K's Object and Ring Managers are added
• The attracted ring is added as object 7 which allows the rings to attract to Sonic when he has a shield in the same way they do around the Lightning Shield does (includes it being added to "Object pointers.asm")
  
• To free up RAM, uncompressed chunks are used
• vladikcomper's Error Handler is added for testing
• Variables.asm is added, containing each new RAM address
• Object placements are edited to work with Sonic 3K's format
• The folder "rings" is added, contain the ring placements for every level in Sonic 3K's format
• The folder "Sonic 1 2005 INIs" is added and edited so SonLVL recognizes the objects and rings as being in Sonic 3K's format and the chunks as uncompressed
• Sonic's inertia SSTs are moved from $14 and $15 to $20 and $21 and the new respawning SSTs take its place.
• The original ring object is replaced with one that spawns a single ring for use in debug mode.

Converting

• To convert your object placement files to Sonic 3K's object and ring formats, use MainMemory's LevelConverter to batch convert with neither boxes checked. The new object file will have monitors converted to object 1 and air bubbles converted to object 55, so they will have to be changed back manually.

Credits

• MoDule for this Object Manager guide
  
• shobiz for this Ring Manager guide
• MainMemory for SonLVL and LevelConverter
• vladikcomper for this error handler

Bugs

• The rings have a higher priority than they should. As a result, they can overlap the HUD.

If you can find any flaws or think of any improvements, feel free to let me know. Bug fixing has allowed me to fix some bugs in my own hack and I'm really happy about that.

 

Hey, nice work! The way you've set the thread out is a nice touch too, it looks clean and functional~

As for the whole rings overlapping HUD bug thingy, I'll help you supply a fix for this. Change this:

Code:

		tst.b	(Level_started_flag).w
		beq.s	BuildSpritesCont
		bsr.w	BuildRings

BuildSpritesCont:
		lea	($FFFFAC00).w,a4
		moveq	#7,d7

loc_D66A:

Into this:

Code:

		lea	($FFFFAC00).w,a4
		moveq	#7,d7

loc_D66A:
		cmpi.w	#$07-$02,d7
		bne.s	BuildSpritesCont
		tst.b	(Level_started_flag).w
		beq.s	BuildSpritesCont
		movem.l	d7/a4,-(sp)
		bsr.w	BuildRings
		movem.l	(sp)+,d7/a4

BuildSpritesCont:

The $02 next to the $07- on d7, this is the priority the rings will use, so you can change the priority if required, the rings in Sonic 1 used priority list 02 originally.

Sonic 2 and 3 won't have this problem as the HUD sprites are manually written into the table before the rings are, Sonic 1 has the HUD as part of the normal object system, thus, its sprites will implement with the rest of the objects. Perhaps you could include swapping out the object HUD for a raw sprite HUD, seeing as the guide is designed to improve on the engine by moving it closer to S3K's system?

 

I would just go away with the HUD object and implement S3K style HUD. Granted, you would need to make extra code for dealing with the stock BuildSprites code...

 

Finally anyone with courage to create this. Brilliant, man!
I'll only not use this because I have my own (my friend created his own) object manager in my Sonic 1 hack. I may go for the rings manager though. But I must say it's very welcome and it became true in a very important time. As seen for some of the new-bie hacks which suffers with the objects disappearing and such kind of problem. Would this be the final solution to the dozen Sonic 1 hacks which suffers with lag and objects not being load properly? Pretty nice job, dude! Certainly this thing will be useful for me in a near future or in a alternate project. Thank you very much!

 

This won't end lag in hacks, there will always be a limit to how much the game can take, but it will definitely help. The 2015 version of Sonic Next Genesis had level design that was the epitome of filling the level with objects that didn't load correctly and I'm pretty sure that adding the object manager fixed that before I changed the level design.

I agree that it would be a good idea to expand upon the engine to add more Sonic 3K features, but I was only intending this to be something small to give to the community. I'll probably get to it eventually. I would add the Sonic 3K priority manager, HUD, level layout (if I figure it out), and how some things behave. Tails and level transitions (not the same method as Sonic 3K) could be "premium" features for those who ask for it and I think deserve it, though I would have to get them to work better in my own hack first. Additionally, I would have to find a good way to make the features easier to individually extract from the disassembly.

Thank you, Markey, for the fix. I added it to the disassembly.

 

Just wondering. Is there any possibilities of a GIT source with this feature by any chance? It would be really helpful for people who're not used to the structure of the Hivebrain's 2005 disassembler (especially because SonLVL no longer supports this version of the Sonic 1 source code).

 

Maybe I'll do it when I return to this. As long as you know the major differences between disassemblies, bringing the managers to the GitHub disassembly should be simple.