![sonic 3 hd sprites sonic 3 hd sprites](https://i.redd.it/90gqjylnhz761.jpg)
Later, when the sprite processor walks through the list, it looks at a bunch of attributes on the SST to figure out how to draw the object. This will add the object's SST to the list of sprites to be rendered during that frame. In order for an object to be rendered as a sprite, it must explicitly request so by calling the Draw_Sprite function once per frame, which is typically the last step of an object's execution. This is because objects are the game's main way of drawing sprites, although several objects do stuff in the background without any visual representation. A more sane approach would be to just use a bset or ori instruction to set the sign bit without messing with the rest of the attribute.Īs you may have gathered, given that the term " sprite status table" refers to the structure that records the status of an object, the two terms are mostly interchangeable. Either that, or it was just human error inputting the new value by hand.
#Sonic 3 hd sprites update#
And therein lies the problem: when the boss is defeated, the lid segments try to set their priority bit, but also accidentally change from palette 2 to palette 1 in the process.Ī possible explanation is that the object did use palette 1 at one point, but when it changed, they neglected to update the value at loc_740AA. The second entry in ObjDat3_74140 holds the value $4425, which when unpacked gives us base tile $425, no X/Y flip, and color palette 2.
#Sonic 3 hd sprites code#
Let's compare this with the setup code for the object. Unpacking this gives us base tile $425, no X/Y flip, and color palette 1. If we flip the signage, we get the value $A425. Setting the sign bit on $A(a0) equals setting the priority flag on the object's sprites, which lines up with what we see in-game: the lid segments usually disappear behind the wall, but pop in front of it when we defeat the boss. This behavior is what prevents you from being able to change which path you're on by simply jumping around inside loops: since the collision change object is only touching the top of the loop and you need to be on the ground to activate it, the only way it can possibly happen is if you're running along the ceiling of the loop when you cross it.Īrgh, another one of those goofy numbers that aren't really negative. Bit 6 is the sprite priority chosen when the player crosses over to the left of the object, or above when the object is horizontal.įinally, if bit 7 is set, the object will only take action if the player was on the ground when they crossed it.Bit 5 is the sprite priority chosen when the player crosses over to the right of the object, or below when the object is horizontal.Bit 4 is the collision path chosen when the player crosses over to the left of the object, or above when the object is horizontal.Bit 3 is the collision path chosen when the player crosses over to the right of the object, or below when the object is horizontal.This is controlled by the next four bits in the subtype, as follows: The object's behavior is decidedly simple: if the player crosses over the object within the span of its length, their current collision path, as well as their sprites' priority, will change to whatever the object says it should. This one is particularly infuriating, because changing it to a word that doesn't start with the letter "B" means the design of the items in the bonus stage no longer makes any sense! Monitors are called "item boxes" or just "items" in the Japanese manuals, and the power-ups Sonic gets from them are known as "barriers" rather than "shields". The following sprite status table lists representative status information that is stored in the RAM 42 for main character (hero) type sprites as well as for various other sprites such as enemies or moving platforms.Īnd sure, "object" is a better term than "sprite" to describe data structures and code style that emulate object-oriented design, and I honor that term because the disassembly uses the "Obj" prefix for objects, but it very quickly gives up and starts calling them sprites anyway: The "path swapper" object was called "colichg" in the original source code, and the term "sprite status table" comes directly from a patent by Yuji Naka himself:Ī Sprite is defined through a Sprite attribute table entry which is stored in VRAM 45 and a sprite status table stored in RAM 42. I do this out of respect for the the game's developers, because those were the names they originally used. And previously I made sure to use the term "sprite status table" over "object status table", even though it stores an object's state. In my last post I made it a point to use the term "collision change object" over the more popular "path swapper".