Corruption is the bane of all things good

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.)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>, <xml>. The supported tag styles are: <foo>, [foo].

More information about formatting options