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".
0 kommentar(er)
