Corruption is the bane of all things good

In this case, it is the corruption of memory. Not that I am getting senile, or if I am - it's not the problem over which I am currently obsessing, at least. It all started ages and ages ago, with the project that actually inspired the blog's subtitle.
I have been working on this game engine for more years than I care to admit. I started out as an isometric tile based RPG engine - but after a while it kinda converted into 3D.
Recently (last yearish or so), I decided that my custom physics wasn't working all that well (although well enough for our CW demo). So I decided to move to a real physics engine - and decided on ODE.
After a couple of false starts (and a lot of pushing this project in front of me), I got around to implementing the map as a geom in ODE, which in turn checks for collisions with its tiles. (You see, it's tile based instead of using quad trees - but I suppose that's the topic of a whole other blog post.)
Now that spheres and boxes were happily bouncing around the landscape geometry, I thought I was good to go with trimesh objects. That's what this image shows. It may look like a box, but it is a box shaped trimesh (I'm saving the teapots until after the debugging stage).
There are six images, they happen in sequence, and they are snapshots from each frame where the object collides with the map. Frame 6 is also the graphical frame directly after frame 5.
Can you spot what's wrong? Not only has the object moved contrarily to every known physical law, but the red lines in frame 6 illustrates the amount of interpenetration between the object and the map as well as its location. Except that they are not even attached to the object.
So, upon reading an excellent article on debugging computer games - I realized this is most likely a result of memory corruption. *sigh*
So, now all I have to do is go over all the usual suspects, compiling with all warnings on for starters. After that, I'll try to debug with data breakpoints - and see if that helps any. Though a problem there is that gdb is off a bit, so it doesn't display the code currently debugged. I've tried running "make clean" and then make again - but something's still off a bit (so variables are not defined when I try to inspect them etc).
Or, well, I suppose I could go write a blog post about it instead. Oh, I just did.
Update on the Samurai: Now I have an alternative flatter distributor cap - so all I have to do is build an adapter to make it fit. (I checked moving the timing mechanism over - and decided against it.)
- By ibnalhazardous at 11/18/2008 - 18:11
- game
- programming
- Thumbnail

Post new comment