I’ve now brought across changes to the core VectorStorm library, which I made during the development of Lord. \u00a0The following is probably only of interest to coders. \u00a0Sorry, everyone else; \u00a0please feel free to skip this post. \u00a0:)<\/p>\n
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. \u00a0Well, I think that’s now the case.<\/p>\n
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. \u00a0These axes are different from those used by OpenGL by default, but it’s the coordinate space that I prefer to work in, personally. \u00a0If 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. \u00a0Sorry about that). \u00a0Previously, ‘x’ was to the left, and ‘z’ was extending OUT of the screen.<\/p>\n
I’ve also modified the way that textures are loaded and freed; \u00a0now you treat them exactly like any other object; \u00a0just ‘new’ or ‘delete’ them. \u00a0Previously, VectorStorm could not deallocate textures, and so would keep them loaded until the program terminated. \u00a0Now it can, and will complain noisily if you don’t free your textures before exiting. \u00a0Of course, textures loaded via a .vec file will be deleted automatically when the display list is deleted. \u00a0Also 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. \u00a0That all happens invisibly, inside the library.<\/p>\n
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. \u00a0If 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.<\/p>\n
Finally, I’ve added a series of “buffer” objects. \u00a0The 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. \u00a0The 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. \u00a0In practice, you can use these exactly like the old vsDisplayList->VertexArray(array, count); code, just instead calling vsDisplayList->VertexBuffer(buffer); \u00a0These work for vertices, colors, and texture coordinates, and soon will work for normals as well.<\/p>\n
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; \u00a0it speeds up rendering by storing the indices directly onto the video card (if supported). \u00a0Check VS_GPUBuffer.h for details on how all of this works, but it should be pretty self-explanatory.<\/p>\n
I have not yet swapped .vec files over to using these buffers, but that would be a good thing for me to do, eventually. \u00a0 I’m sure I’ll get there in the fullness of time. \u00a0:)<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve now brought across changes to the core VectorStorm library, which I made during the development of Lord. \u00a0The following is probably only of interest to coders. \u00a0Sorry, everyone else; \u00a0please feel free to skip this post. \u00a0:) I mentioned once before that folks shouldn’t be using the VectorStorm 3D API until I posted an…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":""},"categories":[4,3],"tags":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/po9WK-7I","_links":{"self":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/478"}],"collection":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/comments?post=478"}],"version-history":[{"count":0,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/478\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media?parent=478"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/categories?post=478"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/tags?post=478"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}