We preserve the original check so that the sphere still changes from green to blue with the same timing that a blue sphere does to red, except all we write to the layout at that point is $A, a dummy blue sphere: 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: After we're done waiting, we write 2 (a blue sphere) to the layout and clear out the collision response slot.On subsequent loops, we run out the timer, and then wait until any of the top three bits in the fractional part of the player's position are set, signaling that we are no longer right on top of the sphere.
The first time through, we change the object at the layout position to $C, and set up a timer of nine frames.Okay, we're now ready to write our implementation of Touch_SSSprites_GreenSphere, which is basically going to be a lighter version of Touch_SSSprites_BlueSphere. Turns out, there's another blue sphere clone in slot $C which is completely unused, so we can just tweak its VDP pattern to point at palette line 4 and use that: We also need to add a dummy green sphere definition to the MapPtr_A10A array, which will serve as our halfway state between touching the green sphere and placing a blue sphere in its stead. This time however, we set the routine to 3, which we'll then define in the off_9DFC array as follows: We write the routine and layout pointer to the collision response slot as usual, then jump to loc_97BE to play the blue sphere sound. It can be found at loc_97EE, so that's where we need to add the object to the collision response list, which will look very similar to the blue sphere handling code: Next, we'll go to sub_972E and look for the yellow sphere handling code.
Sonic mania blue spheres perfect code#
Because we're implementing them over yellow spheres, there's actually something extra we need to take into account: yellow spheres are the only objects Tails will interact with in a Sonic and Tails game, so we have to skip over that code by adding a check for our green spheres flag at loc_92C4: Alright, let's finally start writing our green sphere logic.
0 kommentar(er)
