Phase 3a: splitting world and screen

The world grew to 960x480, sixty by thirty tiles, across three zones, including a wall-jump shaft for vertical scrolling. Anything in world space subtracts the camera before it is drawn. The one exception is the debug overlay, which is HUD and stays pinned to screen coordinates so it does not scroll off.

Frame-rate independent smoothing

The naive cam += (target - cam) * 0.1 ties the smoothing speed to the frame rate. At 120fps it closes the gap twice as fast as at 60. Treating it as a continuous decay, d(cam)/dt = k*(target - cam), and solving over a step of dt gives the factor 1 - e^(-k*dt), which scales properly with real elapsed time. The same trick smooths the look-ahead offset so flipping which way you face does not shove the target 80px in a single tick.

float look_target = CAM_LOOKAHEAD * (float)p->facing;
app->cam_look += (look_target - app->cam_look)
                 * (1.0f - expf(-(CAM_K_LOOK * dt)));
float target_x = player_cx - VIEW_W/2 + app->cam_look;

The camera follows the interpolated player position, not the raw simulation one, otherwise it would jerk at 60Hz while everything else moved smoothly. X uses a faster rate (k=8) than Y (k=4). A slow horizontal camera lets you run into walls that have not scrolled into view yet, but a fast vertical camera bobs up and down on every jump and makes me feel ill. Two different problems, two constants.

← the parkour state machine all posts next: the drone pool and hitscan →