As many of you know, our rapid collider is not 100% GPL compatible.  Thus, the mission of replacing it became a top priority for 0.5, and is one of the major reasons why it’s not released yet.

Well, after a lot of learning how our basic collider works (and still needing to learn more) I’ve got the basic opcode collider functioning somewhat in vegastrike.    That is to say, there is no raycollider yet.   Things are going to be slower than the rapid collider until we work out the general bugs, then we can start turning on optimizations and getting things streamlined.  At that point, we will probably remove the old collider from SVN.   And then after that get things using the raycollider.

In the coming couple of weeks, we’re gonna need people to test the svn head with –enable-opcode turned on in the ./configure script.  Backtraces of any segfaults are good, so are descriptions of performance (both speed and accuracy).    Compilation issues as well.   my hacks to opcode may mean that it doesn’t work on non-64 bit cpu’s or non-intel compatible ones…i dont know.  it’s gotta get tested on those archs.

The first person to leave such a report should do so in the bug triage forum under a topic to the effect of “opcode collider errata” or something.

When using vegastrike with –enable-opcode, dont be surprised if it segfaults or you can fly through things you shouldn’t.   We’re not really using opcode the way it should be right now (so we can mimic rapid collider’s api) so I may have done one or two stupid things in the process.   Hopefully now that it’s in a testable form, other devs can help me fix it up.

Thanks for testing.

This entry was posted on Sunday, February 10th, 2008 at 1:01 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.