I’ve now brought across changes to the core VectorStorm library, which I made during the development of Lord. The following is probably only of interest to coders. Sorry, everyone else; please feel free to skip this post. :)
I mentioned once before that folks shouldn’t be using the VectorStorm 3D API until I posted an “all clear” that I thought I’d worked all the bugs out of it. Well, I think that’s now the case.
The most important change to note is that the coordinate axes (by default) have ‘x’ travelling to the right, ‘y’ up, and ‘z’ INTO the screen. These axes are different from those used by OpenGL by default, but it’s the coordinate space that I prefer to work in, personally. If you have some reason to want to change them for your own use, it’s not difficult to do, as long as you don’t change the handedness (in which case all of the matrix and quaternion maths will stop working properly. Sorry about that). Previously, ‘x’ was to the left, and ‘z’ was extending OUT of the screen.
I’ve also modified the way that textures are loaded and freed; now you treat them exactly like any other object; just ‘new’ or ‘delete’ them. Previously, VectorStorm could not deallocate textures, and so would keep them loaded until the program terminated. Now it can, and will complain noisily if you don’t free your textures before exiting. Of course, textures loaded via a .vec file will be deleted automatically when the display list is deleted. Also note that internally, VectorStorm keeps a cache of loaded textures, so having twenty objects which all use the same texture won’t result in twenty copies of the texture being loaded. That all happens invisibly, inside the library.
I’ve created a new “box” class, which contains information about axis-aligned boxes, both in 2D and 3D, and have adjusted bounding box code over to using them. If you were calling any of the API to do with bounding boxes, you’ll need to make a few minor adjustments to that calling code, but this simplified code within the engine an awful lot.
Finally, I’ve added a series of “buffer” objects. The chief one you’re likely to want to use is ‘vsVectorBuffer’, which is a wrapper around the OpenGL Vertex Buffer Object extension, which basically lets you store data semi-permanently on the video card, so that it doesn’t have to be transferred every frame. The vsVectorBuffer object will transparently fall back to using simple arrays, if it’s running on hardware which doesn’t support Vertex Buffer Objects, so there’s no penalty for using these. In practice, you can use these exactly like the old vsDisplayList->VertexArray(array, count); code, just instead calling vsDisplayList->VertexBuffer(buffer); These work for vertices, colors, and texture coordinates, and soon will work for normals as well.
If you’re a fan of using indexed arrays for drawing triangle strips, there’s a vsIndexBuffer as well, which provides similar functionality to the vsVectorBuffer; it speeds up rendering by storing the indices directly onto the video card (if supported). Check VS_GPUBuffer.h for details on how all of this works, but it should be pretty self-explanatory.
I have not yet swapped .vec files over to using these buffers, but that would be a good thing for me to do, eventually. I’m sure I’ll get there in the fullness of time. :)
Still heavily in progress, but we’re on our way! Proper real 3D lighting in VectorStorm; calculated on the video card and everything, like a proper 3D game!