Asteroid Physics

Work on the physics engine is progressing remarkably quickly! Last week I implemented a fairly nice, albeit basic, collision resolution system. To test it, I set up a sizable asteroid field (~1000 asteroids) and a simple ship. I gave the ship the ability to spew small pellets, which serve to test the collision engine. I'm really, really happy with how painless it is to setup the physics engine: it just takes one initialization call, one "Add" call for each object in the system, and then a "FindAllCollisions" call in the update step. Everything else is automatic - the engine keeps track of the objects, their collision meshes and density fields, and figures out when objects are colliding.

Everything on the screen is collidable, so there are no special cases or exceptions. If asteroids are included in the physics engine, then all asteroids can collide with all other asteroids. If bullets are included, bullets can collide with bullets as well as with asteroids, etc. Everything functions just as you would expect. Finally, the part that really matters - the performance - is really, really good!!! I was amazed by how fast the engine runs. I can get about 1000 asteroids + several thousand bullets on screen at once while maintaining 60fps. That's a lot of colliders! It's really cool to watch bullets collide multiple times off of different asteroids.

There's still work to be done. The system still has a few glitches: bullets are occasionally piercing asteroids, the system could be even faster, and the physics could be more realistic (Newton would be crying if he saw my collision response equations). The next step is probably to implement spatial signatures, just to see if I can squeeze some more performance out of the system. When everything gets tightened up, I'll definitely be recording a video demonstration of it.

All in all, I couldn't have hoped for better luck with the physics engine :) I'm quite proud of it! I think the engine will serve the inhabitants of my reality well.

Procedural Texture

I'm back to playing with texture functions for a bit, mainly because I'm testing a new CPU-side texture generation method that I just implemented to make direct editing/creation of textures on the CPU really painless. The application that creates this texture is < 40 lines of code (no, that's not Python; it's c++!). Yes, it's black magic. Intuitive, scary, black magic.

Same old Perlin nonsense, this time with intentional banding! It looks rather nice. Hence the post.

BitMen

I wish I had something as new and exciting to report as I usually do, but work this month has been slow. Most of the work that's happening right now is internal. I'm cleaning up code, reworking some things, making the engine more logical and intuitive, etc. It's not very glamorous, but it's the only way to keep the engine evolving.

Just so that I can have a pretty screenshot for July, I'll post a shot of a recent demo called 'BitMen.' There's not much to it - just some randomly-placed, glowy men. Why? I don't know. Why not?