Create a custom theme
0
The sprite collision routine is called a lot, and I do mean a lot. it's used to check if a robot can safely move (Wall Avoidance in Berzerk and Wall + Robot Avoidance in Frenzy), figure out if a robot collided with something, figure out if the humanoid collided with something, and so on. So my first optimization was to look it over and see what I could do to make it faster. I ended up replacing a number of things with pre-calculated values that are stored in the space freed up by dropping the digital sample buffer. For example:
became
The if was used to compensate for the right-movement robot's change of the center pixel of the robot. To keep the robot centered, right-moving robots (but not tanks) are displayed 1 pixel to the left of their actual X location, so the collision routine must also compensate. The right2 is used figure out if sprites overlap horizontally. Double2 would have had the value of 8 for 2X sprites (like big otto). The pre-calculated values like the bits in gSpriteState[i] and gSpriteXr[i] are only updated whenever a sprite moves.
The other thing I did was revamp the robot movement routines. I did a couple things there:
1) added a "sleep" timer. When the robot fires, it goes to sleep for 15 movement-frames1. This prevents the robot from rapid-firing at you and saves processing time on it's "sleeping frames". The number of sleep frames will be revised as the game is developed.
2) when a robot moves, it used to do up to 3 Wall/Robot Avoidance checks per movement-frame. The check compares the potentially new location against all other sprites. If it failed it would check the alt1 direction, and finally alt2 direction. The revised routines only do 1 Avoidance check per movement-frame. If it succeeded the robot would move, otherwise a flag is set to try alt1 direction and then processing for that robot ends. If alt1 failed on the next movement frame, the flag would be set for alt-2. On the following movement-frame, if alt2 direction failed the robot would go to sleep for 15 movement-frames. This sleep duration can be a different duration from the one used when the robot fires.
So - the big question is what did these changes buy us? In the prior release I noticed screen jitter starting in room 9 of the Frenzy variation. In today's release I noticed it starting in room 1a (26).
Besides code optimization, some other things I can do to make the game perform better is to 1) reduce the maximum number of sprites the game can handle (it's currently 24 [the 4 shots are not part of the 24]) and 2) decrease the maximum robots that can move per frame.
1 only a limited number of robots move on each frame. As the levels increase, the number of robots per frame also increases. Frames that a particular robot moves are considered its "movement-frame".
ROMs
frantic_harmony_20111003.bin (32K)
downloads: 24
frantic_stella_20111003.bin (32K)
downloads: 30
Source
Frantic20111003.zip (925.38K)
downloads: 19
if (image2_id >= ROBOT_RIGHT_ID && image2_id <= ROBOT_RIGHT_ID + 7)
{
left2--;
right2--;
}
right2 = left2 + 8 + double2;
became
if (gSpriteState[i] & 0x100)
{
left2--;
right2--;
}
right2 = gSpriteXr[i];
The if was used to compensate for the right-movement robot's change of the center pixel of the robot. To keep the robot centered, right-moving robots (but not tanks) are displayed 1 pixel to the left of their actual X location, so the collision routine must also compensate. The right2 is used figure out if sprites overlap horizontally. Double2 would have had the value of 8 for 2X sprites (like big otto). The pre-calculated values like the bits in gSpriteState[i] and gSpriteXr[i] are only updated whenever a sprite moves.
The other thing I did was revamp the robot movement routines. I did a couple things there:
1) added a "sleep" timer. When the robot fires, it goes to sleep for 15 movement-frames1. This prevents the robot from rapid-firing at you and saves processing time on it's "sleeping frames". The number of sleep frames will be revised as the game is developed.
2) when a robot moves, it used to do up to 3 Wall/Robot Avoidance checks per movement-frame. The check compares the potentially new location against all other sprites. If it failed it would check the alt1 direction, and finally alt2 direction. The revised routines only do 1 Avoidance check per movement-frame. If it succeeded the robot would move, otherwise a flag is set to try alt1 direction and then processing for that robot ends. If alt1 failed on the next movement frame, the flag would be set for alt-2. On the following movement-frame, if alt2 direction failed the robot would go to sleep for 15 movement-frames. This sleep duration can be a different duration from the one used when the robot fires.
So - the big question is what did these changes buy us? In the prior release I noticed screen jitter starting in room 9 of the Frenzy variation. In today's release I noticed it starting in room 1a (26).
Besides code optimization, some other things I can do to make the game perform better is to 1) reduce the maximum number of sprites the game can handle (it's currently 24 [the 4 shots are not part of the 24]) and 2) decrease the maximum robots that can move per frame.
1 only a limited number of robots move on each frame. As the levels increase, the number of robots per frame also increases. Frames that a particular robot moves are considered its "movement-frame".
ROMs
frantic_harmony_20111003.bin (32K)
downloads: 24
frantic_stella_20111003.bin (32K)
downloads: 30
Source
Frantic20111003.zip (925.38K)
downloads: 19
