ADDED (7/31): Fixed some missing interactions; elastic collisions apply to the ship; re-did overlay; you can switch views; gravity calc is dropped at high distances.

Press 'Z' to switch views among ship and planetoids. Current view is displayed in overlay.

ADDED (7/31): Only detect collisions for nearby objects (fixes integer overflow issue).

ADDED (7/31): Elastic collisions (for planetoids), sound and music.

I've implemented perfectly elastic collisions between the planetoids. (I haven't done collisions for the ship, yet, partly because it's easier to detect collisions for circles.)

When two planetoids collide, a crashing sound plays and the planets exchange some energy and momentum (details). I'm pretty sure the math is accurate -- at least, the collisions look reasonably accurate. As with gravity, however, the math involved can involve large numbers and integer overflow could be a problem -- I don't know whether it actually does cause issues in the conditions I've built. (EDIT: I think it does. In particular, collision detection uses distance. But, because of integer overflow and sqrt, distances over ~181 roll back to 0. So very distant objects constantly collide with each other and go crazy. This makes the system less stable than it should be. A solution would be to only check collisions for nearby objects, using some cheap and safe heuristic (e.g. Manhattan distance).)

One thing that the new logic makes obvious is that the initial conditions are not dynamically stable. The first collision will happen after just a couple orbits, and then a lot more collisions will happen. If you let it run for a while, the planets will line up and do a huge croquet shot, sending at least one of them off into infinity.

I'm starting to think there might be a workable game in the neighborhood of *space billiards*.

Sound: just fiddled with the sfx toy to get something noisy.

Music: naive implementation of Bach, Prelude No. 1 from the *Well-Tempered Clavier*.

To do:

- Collision detection and physics model for the ship.
- Start thinking about what space billiards would be like.
- Can the sound be made into an interesting function of the collision, e.g. scaled somehow to the energy of the bodies?

UPDATED (7/30): Added third body (plus ship), de-uglified map. Sim should now start in a kinda-stable three-body configuration.

This is an extremely sketchy little orbital mechanics demo. It mostly happened because I was trying to learn about the camera! Now it is a pretty barebones 3.5-body simulator.

Arrow keys give thrust in direction of arrow. You are limited to 50 delta v units (approximately 1px / frame^2 total I think).

Thrust is meant to be used sparingly or you will fly off into boring space.

Things I might do if I'm interested in this later:

- Add more bodies
- Add more gravitational interactions between bodies
- Add collision detection (stop and / or explode when you land on a planetoid!)
- Figure out why the camera sucks
- Figure out how to draw more map
- Add something resembling a game (e.g. get to point X with only Y delta v)

Neat! But I seem to be orbiting a point about 16 or so pixels south east of the main planet rock thing.

Good eye! I mis-guesstimated how big the sprites are and there's an extra offset in there. Fixed in my local version.

Right now I am more confused about why camera offset stops working. The cart also crashes PICO-8 on my local machine, not sure exactly when.

Diagnosis: the distance calculation in the gravity physics is falling down at high distances.

Why? Not sure yet!

Calculation looks like:

>r = norm(disp(ship,planetoid))

>

> function norm(v)

> return sqrt(v.x^2 + v.y^2)

>end

>

>function disp(v,w)

> return {x=v.x-w.x, y=v.y-w.y}

>end

Ok, here it is: integer overflow happens really quickly when you are adding squares of 3-digit numbers!

Not sure how to work around, as the calculation uses square distances and square distances exceed 32K pretty quickly. I could use a unit bigger than pixels.

Maybe there is a way to estimate distance with smaller numbers.

Without looking at the specifics, one thing to keep in mind is that number values in P8 are fixed point 16.16 values, which I think means in practice you can get into mathy trouble as soon as you try to deal with any number bigger than +- 2^15. Which means maybe that v.x^2 and v.y^2 will give you trouble once they get somewhere north of 2^7, depending on how how not-fucking-around the implementation is about this.

I think the sqrt crash bug is a known issue, at least.

Yeah I wound up using the workaround from <a href="https://www.lexaloffle.com/bbs/?tid=2083">here</a>;. I *think* that has the effect of zeroing the gravitational force for about r > 2^7, in my cart.

[Please log in to post a comment]