Raccoon Sam wrote:Is there a byte that sets that or something? Or are there separate phys-tiles for 'walkable but not jumpable-through from below'?
It's in fact a bit, that is set per each 16x32 tile (I was right on the assumption in my previous post).
Each physical tile in the physmap takes up one byte, and there are two of these for every 32x32 tile in the tileset. Note that the bytes are stored in the format LLRR
in ROM, where LL
is the left tile and RR
the right; this data isn't stored in Little-Endian format
.As for the format of the data itself, each byte is organized like this: HJTTTTTTH
= If set, the phys-tile will be flipped horizontally.*J
= If this bit is enabled, you can jump through the platform.TTTTTT
= This is a 6-bit value ($00-$3F) identifying the structure of the physical tile.*
If the 32x32 tile in the tileset is also flipped horizontally, this bit has the inverse effect.**
Also, note that the physical tiles are never affected by a vertical flip of the 32x32 tile.
Those numbers you see on the screen are some variables which I'm using to test my replica of DKC's physics.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 formulaspeed = ((((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
, 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.