today's work is absurdly light, unfortunately. i mostly did some research and made some decisions on how i should be dividing responsibilities between regular and fixed updates in Unity.

see, the concern i have is about this philosophy that Unity (and other game engines) seems to imply through the kind of implementation it recommends: the screen is essentially a viewport into a physics simulation that allows user input. to keep the physics stable, it updates at 50 updates per second. but the screen updates at 30, 60, 144 or whatever framerate as long as it doesn't interfere with the physics fixed update rate.

since the player moves according to the physics rate, i made jumping calculate from there too. but now, when i account for special timing like pressing the spacebar early or coyote time, input windows are physics dependent and not framerate dependent. i think this may be a necessary evil, and it begs the question of why i want the framerate / input and fixed rate / physics to be so decoupled from one another. also, is this really that coupled? maybe it's just an interesting thing to think about, more than anything else.

also i'm pretty sure it's what's causing the camera to jitter still. so there's that.