Sonic and Sega Retro Message Board: LZ water ripple in s2 - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Loading News Feed...
 

LZ water ripple in s2 easy to implement, but has it's downsides

#31 User is offline MoDule 

Posted 15 September 2008 - 10:56 AM

  • Posts: 304
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52

View Postshobiz, on Sep 15 2008, 04:20 PM, said:

Well, I've gone through the S3K object manager and done some labelling and commenting - I uploaded the result some time ago, it can be seen here and might be helpful to you.

Thanks, that should be pretty helpful, though it doesn't look like you got much further than I did. You do seem to have figured out a few more ram addresses. It looks like you couldn't figure out $FFFFF712, either. It doesn't seem to be used anywhere else.

View Postshobiz, on Sep 15 2008, 04:20 PM, said:

As for respawning, as far as I know it's pretty simple in Sonic 3K. Each object is assigned a one byte entry in the object respawn table, which is $300 bytes, meaning a maximum of 768 objects in one level's object placement. Now, whenever the object manager loads an object, it sets bit 7 of its respawn entry. During the object's lifetime, this bit remains set. Now, in general there are two main ways an enemy object (for example) is destroyed - either it goes out of range and MarkObjGone comes into play, or else Sonic kills it. In the first case, MarkObjGone clears bit 7 of the object's respawn entry, indicating that the object hasn't been destroyed and should be re-loaded when it comes into range (hence the proper name for that subroutine would be MarkObjNotGone). In the second case, however, bit 7 remains set, and so next time the object comes within loading range, the object manager sees that this bit is set and skips object loading. Note that some objects use the other bits of their respawn entry as well - for example, monitors set bit 0 to indicate a broken monitor.

The main difference between Sonic 2's object manager and Sonic 3K's, apart from the Y position loading checks the S3K manager adds, is that in Sonic 2, only some objects are assigned respawn entries, while in Sonic 3K all objects in a level's object placement get a respawn entry. Consequently, the high bit of an object's Y position also has a different function in both games. In Sonic 2, the high bit being set indicates that the object should be given an entry in the respawn table, whereas in Sonic 3K, the high bit being set indicates that the object should be loaded whenever it is in X range, even if it is out of the normal object Y loading range. I'm guessing you've seen it before, but SCHG:Sonic 3 & Knuckles/RAM Editing contains info which may be useful to you.

Thanks for the explanation. I've read it on the wiki before, but yours went into a little more detail.

#32 User is offline shobiz 

Posted 15 September 2008 - 12:32 PM

  • Posts: 863
  • Joined: 27-March 05
  • Gender:Male
  • Location:Karachi, Pakistan
  • Wiki edits:4,411

View PostMoDule, on Sep 15 2008, 09:56 PM, said:

It looks like you couldn't figure out $FFFFF712, either. It doesn't seem to be used anywhere else.

As far as I can tell, it was intended to be used as the object respawn table for those levels using that routine of the object manager. Dunno if it's used though.

  • 3 Pages +
  • 1
  • 2
  • 3
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users