Add particle physics (explosions)

[parasyte]

TODO:

• Move particles.
• Apply gravity.
• Apply friction.
• Detect collisions.
• Apply collision reaction.
• Particle decay.
• Particle fade.
• Particle death.
• Scale by dt.
• Break Shields.
• Laser-to-bullet explosions.
• Explode the tank when an invader touches earth.
• Refactor collision.trace() into multiple functions.
• Replace the naïve collision reaction with a loop that walks the ray through all reflections along the trajectory.
• Force particles to escape entrapment by moving entities; walk the trajectory until freed.
• Investigate vek as a replacement for home-grown geometry primitives.
• Investigate xcf as a replacement for inferred collision shapes and pcx.
• Cleanup all TODO comments.

[parasyte]

I am considering reworking the collision shapes. It's kind of a long story. TL;DR: I was lazy, so tried to infer collision shapes from the frame buffer. It has bugs.

The typical way to handle collision shapes in physics simulations is by creating a mesh in some kind of editor, like Blender or whatever. There's even a pretty awesome looking blend crate for this. But that is way too much work for simple-invaders.

When working on melonJS, I had a fairly good experience with Tiled. Using the polygon and polyline object types is great for physics simulations. But even this feels too heavy for simple-invaders. I'm not even using a modern image format. I'm using the most simple format I could think of; PCX!

So I opted to infer collision shapes instead of winding them around my sprites by hand. The inference is done by grabbing a 5x5 block of pixels from the frame buffer and wrapping a convex hull around it. But, which 5x5 blocks are used? As a particle moves through the scene, its next position is predicted by adding the velocity. Then a ray is traced from its current position to its predicted position (using the Bresenham line drawing algorithm). Pixels in the frame buffer are checked along the ray, and when a "hit" is found, it is used as the center of the 5x5 block.

This does actually work. It's not terrible. But there are inescapable problems. The most noticeable issue if that when particles are moving nearly parallel with the floor, they will sometimes hit invisible "ledges" that causes them to fly away at an unexpected angle. This is mostly caused by the "diamond shape" that each pixel is given, and partially by the relatively small size of 5x5 pixel shapes. With the floor, this is even worse since the longest the floor can be (relative to a particle's perspective) is 5x1 pixels. This gives it plenty of opportunity to clip the edges of this small part of the floor.

So, are there better options? Maybe. Right now I'm considering using xcf as a replacement for pcx, which will give me the chance to use vector shapes (paths) right on my sprite assets. Though from a quick glance at the crate docs, it looks rather incomplete. Properties are supported, but I will have to parse the path data on my own... The documentation for the format is not great (I've written code for it before) but at least something is available: https://gitlab.gnome.org/GNOME/gimp/raw/gimp-2-10/devel-docs/xcf.txt

That's the story so far! I will at least explore using xcf, even if it doesn't turn out well. I suspect it will be better than inferring shapes from arbitrary patches of pixels, though.