Jeff Harris

Software engineer, hobbyist game developer

Gamedev with friends = awesome

Had a great gamedev session last night with my mate lawrence. Were both working on XNA projects and it really helps motivation to have someone else kicking your ass for not getting stuff done and helping find bugs. Rock Band, funny movies, coffee and game coding… awesome :)

I fixed an annoying bug thats stopped me getting on with 3d audio - some sounds played at 2x the volume of other sounds, and it was pretty random when it happened. Pre-loading all the sounds before the game starts (instead of loading them the first time they’re needed) fixed it. Not sure why that fixed it but glad to be back in gamedev mode!


So long WindowsXP, thanks for all the memories!

I’ve finally upgraded my main dev box to Win7 from WinXP (which I’ve used for the last 10 years!). I skipped Vista entirely, and only upgraded now because I figured I should. So between work, life and upgrade problems I havent done anything on OpenCarma lately. So theres really no point to this blog post :)


Carmageddon Crush Data decoded

Since there have been several attempts to understand the C1 Crush data, I’ll document it here, as far as I’ve worked out.

There are two header sections marked with // CRUSH DATA. The first might be used only in low-mem mode, as it doesn’t contain any crush positions, so I ignore it in OpenCarma.

Heres what the second header looks like:

// CRUSH DATA
0.450000             /* damage multiplier.  This is lower for strong vehicles and higher for small, light vehicles */
0.150000,0.400000    // unknown.  seems to always be the same
0.050000             // (same)
0.050000             // (same)
0.000000             // (same)
0.000000             // (same)
93                   // number of vertices participating in crush

Next, a section for each of the 93 vertices (in this example) which are checked for crushing:

65                          // index of this vertex
-0.1682, -0.1328, -0.4427   // min position that this vert can move to
-0.0682, -0.0540, -0.3427   // max position that this vert can move to
0.0121, 0.0156, 0.0062      // multipliers for left, top, rear collisions
0.0378, 0.0234, 0.0437      // multipliers for right, bottom, front collisions
74                          // number of child vertices to move if the main vertex is hit

Next, a section for each child vertex.

// ----- (child vertex 1) -----
5        // vertex reference. This must be added to a counter which starts at -1 and incremented for each child vertex. So this actually references vertex 4 (-1 + 5) in PlayThing
178      // distance of this vert from the parent vertex

// ----- (child vertex 2) -----
5        // vertex reference. This is vertex 5 in PlayThing (-1 + 1 + 5)
133      // distance of this vert from the parent vertex

// ----- (child vertex 3) -----
5        // vertex reference. This is vertex 6 in PlayThing (-1 + 2 + 5)
117      // distance of this vert from the parent vertex

And so on for the other 71 children (in this example)

Hope that finally clears it up :)