Seriously. I’ve known about a bug in my collision detection routine for some time now. Once in a while, for no particular reason, instead of bouncing off of a tower, the ship will get stuck. It didn’t happen all the time. In fact it only came up maybe one out of every 50 collisions. But it was there. And I knew I had to tackle it.
I will spare you all the boring details of every single tiny little thing that I tested. Really… they make me want to pull my eyes out. I tore everything apart, including my hard won math formula for calculating the bounce angle. ( This was much harder to find help on than it should have. ) In case any wayward travelers stumble here from Google, this is how it’s done:
vector wallNormal;
vector shipMotion;
vector angle = wallNormal * (DotProduct(wallNormal,shipMotion) * 2);
shipMotion -= angle;
Anyway, after banging my head for a few hours, turns out I simply wasn’t updating my Bounding Box before every collision test. That’s all. Kill me now.
For those who don’t know, a Bounding Box is, well, a box. Think of it like a fence around your ship ( or bullet, or anything else you want to check collision with ). It’s much faster to calculate whether you’re colliding with a four sided rectangle rather than a complex shape like a ship.
In addition, for accuracy’s sake I need to check discrete changes in your ship’s movement from frame to frame to ensure that you don’t automatically jump over a bullet or other object you should have collided with. So each entity’s movement each frame is subdivided by four, and I check for collisions for each of those four sub-movements of every entity… every frame. It sounds like a lot, and frankly it is. However, ensuring that two entities don’t pass through each other is absolutely crucial.
Anyway, that was where my mistake was: I had an accurate Bounding Box at the beginning of the check, and I had one when it was finished. But I had forgotten to update the Bounding Box for those in between checks.
Some other work I’ve gotten done lately:
- Created a custom file format for 3D triangle meshes, called Angular Velocity Vertex Lists ( file extension .avvl ). It’s mostly just binary arrays of floats that represent vertex, normal, and texture coordinate data and should be super fast to load.
- Created a conversion utility that will read a Wavefront .obj file and convert it to an .avvl. Most every 3D modeling program can export to .obj, so it was the natural choice.
- Set up Angular Velocity to read .avvl files for entities instead of just textures on sprites like they have been. The cool thing here is that if I create an entity who’s config file passes an image instead of a VertexList, it will automatically create an internal VertexArray sprite and assign that image as the texture, correctly sizing it based on the texture’s width and height. This is big because it lets me continue working on the game with my current sprite assets, but when I’m ready for a Mesh I just have to drop it in the config and AV will just figure out what to do with it. No re-coding required.
- I beefed up the Keyboard input routine to prepare it for chat and console. Yawn.
That’s it for today. Sorry no new sexy screenshots, but hopefully by this weekend I’ll have a few new tile types that will be worth looking at. Perhaps even a 3D ship model. Stay tuned.