Well, I think that I may have finally cracked the last major problem with VectorStorm’s 3D support; I had another pretty major bug in the rendering code, which was ending up having cameras render with the incorrect field of view (generally about 20-30% wider than it was supposed to be), which was completely throwing my mouse code for a loop.
I now have mouse-based 3D picking working correctly in Lord, which means that I believe the last major tech hurdle has been cleared. I’m now hoping to have Lord completed this coming weekend.
Of course, I haven’t actually prototyped the gameplay yet; all my spare dev time has been going into sorting out the tech issues. So even having run to three weeks instead of one, it’s still going to be a bit scary to see whether the game itself actually turns out to be fun! The time definitely hasn’t been going into fine-tuning the gameplay mechanics any more than usual…
Of course, I can’t post a post-mortem until after I finish Lord, but I think I can safely say that VectorStorm wasn’t ready to have a 3D game made with it; particularly not on a short schedule, like my GiaW games have!
I was hoping to have Lord completed this weekend, but I’ve been running into one major engine bug after another all week. The most recent one is that the 3D camera code math was entirely broken. If there are any programmers out there using the VectorStorm library for anything, don’t trust any of the 3D code in it until I’ve given the all-clear; the camera<->OpenGL code was entirely broken, and I suspect that some of my 4×4 matrix math is still broken. The 2D API is still fine, but 3D is probably busted until further notice.
I’ve been adding support for the OpenGL VBO extension to VectorStorm; this allows 2D and 3D geometry data to be uploaded directly to the video card, so that it may be rendered rapidly without hogging memory bandwidth between the CPU and the GPU. Which translated into non-technical terms means that VectorStorm can render far more without dropping frame rate, when using the new VBO classes (Note that currently, nothing is actually using these; I’ll need to adjust loaded display lists to use these automatically, instead of using the old, slower “vertex arrays” approach).
Note that the VBO extension isn’t universally supported; it requires OpenGL 1.5, which means that if your video card was made in the last four or five years, it probably supports it. But it’s not guaranteed. If VBOs aren’t supported, VectorStorm emulates the VBO functionality internally, and it should be no slower than it would be using the older rendering interface.
This new tech will eventually make it back into the VectorStorm trunk; probably sometime after I finish up this increasingly-mislabelled “Game in a Week”. 
Rendering of the distorting Lord terrain map has been swapped over to use VBOs. This has sped up some of the terrain rendering code, but calculating the vertex distortion is still by far the most expensive part of the rendering; I’ll need to find an optimisation before Lord is released, or else it’ll have absurdly high system requirements for what it’s actually doing. Or I could bite the bullet and disable the terrain distortion; that’d speed everything up dramatically.
I’ve also picked music for Lord, have implemented a credits scroll, and started on an introductory sequence. But there’s still a fair whack to do before the game is finished.
“Lord, save us from that horrible land” screenshot for the day.
Added automatic mipmaps to VectorStorm textures. Major optimisations to map drawing. Added tonal variation to map coloration.
More engine bug fixes for the rendering of textured geometry.
So I’ve actually slipped a day on this GiaW. Not going to say too much in this update; want to get back to work on it. However, it now seems pretty obvious to me that I rushed into this GiaW sooner than I should have; the 3D features of VectorStorm just weren’t quite solid enough to support rapidly developing a 3D game; too much of my time was lost debugging basic engine stuff, instead of developing the game itself.
Still hoping to have something by the end of the day today. But we’ll see.
