I got to wondering whether you could rotate a sprite in PICO-8. Of course this facility is not provided, but it should be achievable, I thought.
How this works: 3 rotating objects. Arrows move the green cursor among them, and Z or X to toggle each object on or off.
The rotations are slightly ugly, but I think accurate. Smoothing could probably make them look better, but maybe not at reasonable cost. I don't know! Rotating the large sprite is CPU-intensive (and ugly!). I think for small objects this could be used in a game.
Issues:
- Sprites are rotated about their top left corner. I think this is needed to guarantee that atan2 is one-to-one. But it would be better to rotate around an arbitrary center!
- I forgot what the other issues are.
12 comments
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.
