FPS: DKC's engine runs at 60FPS but its graphics only display at half of that - 30FPS. This is of course if you're running it on an emulator. I use 60 rather than 50 because the game timing calculations become much easier.
- Speeds are represented as 8.8 fixed-point hexadecimal values.
- So a speed of 0x0100 means one pixel per frame, 0x0080 is half, etc.
- So to get values to input into a GM game, simply divide the numbers by 256.
This can be done easily using Windows Calculator - Donkey Kong's starting gravity (Y target speed) is 0x0300, and he can only fall as fast as 0x0800
- Donkey Kong's walking target speed is 0x0200, and his running target speed is 0x0300
- When the jump button is NOT held, 0x0070 is added to DK's Y Speed every frame.
- When the jump button IS held, 0x0048 is added to DK's Y Speed every frame.
- speed = ((((targetspeed + 0) - speed) >> 3) + speed);
Target Speed - This is how fast DK should be moving when he is no longer accelerating.
So if you start walking right, his target X speed becomes 0x02.00
0 - This zero is a placeholder for the drag value, which is used to push DK to the side if standing on a slippery slope.
>> 3 - This is actually not 3 all of the time. It's 6 in ice/snow levels. It determines how fast DK accelerates.
Basically equivalent to dividing by 8, or 64 in ice levels.
Donkey Kong's gravity is determined by whether the B Button is pressed. So even if DK is on the ground, holding down B will make him hit the ground again slower. Of course the default gravity of 0x03.00 is fast enough that you never have DK falling twice on slopes to hit solid ground (you shouldn't see DK in the air for a frame, he should just hit the ground immediately).
1. Each time DK hits the ground, his Y Speed is reset to 0x03.00.
2. When the B button is initially pressed, DK's Y speed is set to 0xF9.00 (a negative value, that's -7).
3a. If the B button is held (at any time), 0x00.48 is added to his Y speed (this is gravity) each frame.
3b. Any time you are not holding down the B button, 0x00.70 is added.
4a. Target walking speed is 0x02.00 (that's 0xFE.00 going in reverse),
4b. while the running target speed is 0x03.00 (that's 0xFD.00 going in reverse).
X,Y at 0,0 is at the top-left with coordinates increasing to the right and bottom. And also, all of the physics values are signed.
Small detail regarding DKC only: Actually DKC's Y axis is the reverse of the coordinate system I just described, but I don't recommend programming it like that as it can get confusing quickly. Rare got rid of the reversed Y-axis in the other two games, possibly because of a design conflict.
DKC exhibits a strange behavior in its physics engine that can only be described in numbers:
Suppose you have a target speed of 0x0200, and so far it has accelerated to 0x01F9. Apply the formula
speed = ((((targetspeed + 0) - speed) >> 3) + speed);
to this, and you still end up with 0x01F9. Why? well look at it this way... subtract the speed from the target-speed, and you get 7 - this is 00000000 00000111 in binary. But notice that it shifts right 3 times in order to divide by 8; in this case the result is 00000000 00000000, and so nothing is added to the speed to make it inch towards 0x0200.
What DKC does when it reaches this "speed block" isn't necessarily the most accurate solution... it simply jumps straight to the target speed, in this case 0x200. Which means that (from what I gather) rightward movement will loose some accuracy compared to moving left.
But this won't happen when going down, say from 0x0007 to 0x0000, because when 7 is subtracted from the target speed, you get a negative number which has ones in front... -7 would be 11111111 11111001. Shift that right 3 times, and the result is always 11111111 11111111 which means -1. So, in this case it will continue down to 0x0000 instead of getting stuck.
