Blue spheres sonic7/6/2023 ![]() As soon as these are different, it is safe to place the blue sphere in the layout. Now we can repeat the same calculation in Touch_SSSprites_GreenSphere, and then compare it against the stored value. To do this, we will first write the player's position to the collision response slot at loc_97EE: Before placing a blue sphere however, we must ensure that the player has since moved to another layout cell. For red spheres, it is sufficient to wait until we are no longer at the center of the intersection before placing them in the layout. This explains the mismatched behavior between blue spheres and red spheres. We're waiting until all of them are cleared! Red spheres only activate if we're right on top of them! However, this time we're not waiting until any of them are set. When the object at the player's current position is 1, a red sphere, we are once again we are checking the top three bits in the fractional part of the player's position. If we continue reading, we'll soon run into some very familiar code: That's not really the relevant part, though. This effectively rounds the player's position towards the closest integer, which means that if we're walking from position A to position B, then we will touch the object at position B as soon as we're closer to B then we are to A. Note how before we truncate the player's X and Y coordinates, we add onto them a fractional value of $80, or 0.5. So what is the reason for the discrepancy between red and blue spheres? Why do we collect the blue sphere as we're walking away, but not activate the red sphere in the same circumstances? The answer can be found at sub_972E: Although our green spheres correctly only turn blue once we've walked past them, we end up collecting those immediately after, leaving behind a trail of red spheres as we go. If we build and test the ROM right now though, we'll soon realize there is a problem. So let's go ahead and turn that into code:
0 Comments
Leave a Reply. |