Useful for room shapes which cannot be handled by standard visibility
checks.
Normally this can be addressed with additional rooms and doorways, but
sometimes a room is required to be a complex shape (for example, to
accomodate animated static geometry).
These instances should be few and far between, so leaving this as an
opt-in feature that can be used during level authoring.
* Doorway normals now always point toward room A. This was intended
and code was written for it, but typos prevented it from working.
* Consistent doorway directions allowed resurrection of previous
collisionSceneRaycastDoorways() implementation
Standard culling is quite coarse, for performance reasons:
* Only uses axis-aligned bounding boxes
* One visible object in a BVH node will make all others in the same node visible
These properties allow the bounding boxes of rotated objects to clip through
the back of portals to be considered visible, causing improper rendering.
This commit introduces a new optional argument for `@static` level
objects: `precise_culling`. Static geometry marked for precise culling
will be culled based on its exact (i.e., rotated) bounding box, in the
same way dynamic/animated geometry is.
Precise culling is more expensive than standard culling so it is opt-in.
It is intended only for the few situations that can hit the edge cases
described above.
The player's bounding box was not reinitialized on save file load,
causing the collision detection area to include the space between the
level's starting point and their current position.
In large levels (i.e., chamber 15) when far away from the start, this
caused the internal collider limit to be exceeded resulting in a buffer
overflow and crash.
Previously, all activated catchers would reference the same ball
when saving, causing position and signal issues if the referenced
ball's launcher was in use.
Fixes glitchy ball movement in chamber 15 final room.
The previous implementation handled flings in any horizontal direction.
However, this allowed moving against flings by first moving slightly
perpendicularily to them. In other words, the fling direction could be
changed midair allowing free movement relative to the original direction.
One way to solve this is by saving the initial fling direction (direction
of travel while in air and FLING_THRESHOLD_VEL is reached). For simplicity
and to minimize errors, just consider movement axes individually. The
game's levels only permit axis-aligned flings anyway.
* Moved player sound code from scene.c to player.c
* Moved platform position/velocity update to playerUpdateFooting(),
which is where the other related platform code is
* Moved player footstep state update to playerUpdateFooting()
* Created separate function for processing player input
* Created separate functions for movement and acceleration
* Removed some redundant code
With acceleration now separate, movement physics are ready to be
updated.
