Greetings. Ancient individual here.

I wanted to give a proper explanation of how all of the subframe trickery I used in the lunar lander save actually works. Brace yourself, this post may get long.

Equations of Motion

Differential equations govern all natural laws that we know of, so it's a good idea to get the vibe of them early. First of all, we need to introduce the players:

x = position
dx/dt = v = velocity
dv/dt = d^2x/dt^2 = acceleration

"df/dt" means "rate of change of f". In the discrete space of TPT though, we can't take continuous derivatives - instead we have to approximate the instantaneous rate of change by a short-term average rate of change -

v(t) = dx/dt ? (x(t+?t) - x(t))/?t
a(t) = dv/dt ? (v(t+?t) - v(t))/?t

This gets us somewhere. Setting ?t = 1, you can rearrange these equations to read

v[t+1] = a[t] + v[t]
x[t+1] = v[t] + x[t]

i.e. if you know the initial conditions (x[0], v[0]) and the value of the acceleration a[t] at all times, you can iteratively update x and v.

This simple-minded approach is known as Euler integration, and it's well known as one of the lousiest numerical integrators out there. What it lacks in sophistication though, it makes up for in ease of use. Since this is a game about drawing colourful blobs on a screen, I don't think the loss of accuracy is going to bother anyone.

All of the adder modules in the save are colour coded by function - the two orange adders update x[t] and y[t], and the green adders update vx[t] and vy[t]. I'm using signed integers for this (implemented very sloppily, but hey, it works) because floating point hardware is hard.

Newton's laws

To get the acceleration, we need an extra ingredient: Newton's second law, F/m = a.
F represents the total summed forces on the spacecraft, and m its mass. The only source of forces in the x direction is the engine, but y feels the combined effect of the engine and gravity.

Here's where I had to get creative - to get the force in the x (y) direction, I need the cosine (sine) of the ship's tilting angle. I cheated here, and just stored precomputed values in some FILT next to the little GOO sprites.

I had real problems with 1/m. As the rocket burns its fuel, it becomes lighter, which is a key part of the original game (and rocket mechanics in general, actually). Actually calculating it is a pain - in all of TPT, I don't know of any division module that works for signed integers. Since I need to go left and right, that's a non-starter. Instead, I stored around 200 values of 2^8/(m+m_0) in a line of FILT ROM, multiplied by the pre-calculated cos(theta), and then bitshifted to get back to a sensible number. This whole mess is colour coded pink.

The rest of the save consists mostly of spaghetti wifi implementing the game interface.

This post was rushed, if you want a better explanation of anything hmu

Aside: The Rocket Equation

You might be wondering how this related to delta-v in Kerbal Space Program. The idea is that X much fuel can only change your velocity by a fixed amount. If we assume that the force from the rocket engine is proportional to the rate of mass loss,
F = I_{sp} dm/dt, then we get

v_f - v_i = ?_[t_i to t_f] dv/dt dt = ? F(t)/m(t) dt = ? 1/m F(t)dt/dm dm = Isp ln(m_f / m_i)

The theoretical delta v of this moon lander is roughly

I_sp = 45633*0x30/8 <<2^8 = 3224 px/frame<br/>m_wet = 287, m_dry = 92

?v_theory = 38937 px/frame

How does this compare with the numerical approximation? Badly, I imagine, but I cannot be bothered finding out.