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).
- The light-blue areas are jump-through, while the darker blue tiles are solid.
It also now uses some fancy translucency effects, as I've been wanting to test that for some time.
- PhysicsDisplayBeta2.PNG (31.42 KiB) Viewed 148345 times
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 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.
or 
and then run away like this 
— Just joking, anyway who knows what happened..?") 
.
