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 35342 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.