(warning: \u00a0the rest of this post contains dangerously boring technical details)<\/em> change how VectorStorm renders.<\/p>\nOriginally, VectorStorm was designed for rendering simple 2D vector graphic games. \u00a0As such, it was designed with a system of “layers”. \u00a0Your game could configure how many layers it wanted to use, and register sprites or other objects onto any layer you liked. \u00a0Within each layer, objects were drawn in order, with later objects (or later layers) drawn on top of previous layers. \u00a0With vector graphics, since you only had additive lines and no solid objects, the whole issue of which line was on top really didn’t matter; \u00a0the layers were really used just for putting objects under different cameras. \u00a0For example, in The Muncher’s Labyrinth, the game world was in one layer, and the HUD was in a different layer, just so the two could be rendered using different cameras and I didn’t need to worry about moving the HUD around to match the camera. \u00a0When I added solid rendering for ThunderStorm, the layers worked really well to ensure that some objects would always draw in front of other objects.<\/p>\n
Each renderable object would have a “Draw()” function called on it, being given a pointer to a display list to which it could append its own rendering commands. \u00a0This was (in my own opinion) simple and elegant, and it was great for a while.<\/p>\n
But now that VectorStorm is rendering in 3D, layers don’t really make sense any more. \u00a0We still have them, but in 3D we have a z buffer which automatically lets the closest object be drawn, regardless of whether it was drawn first or last, so it’s usually no longer important to manage which objects are drawn first or last, except for in special circumstances (glow effects, transparency, etc).<\/p>\n
But the real problem is that we now often have objects which have different drawing styles within a single object. \u00a0For example, the cursor in MT2 (and MT1, for that matter) is made up of two parts; \u00a0a dark background, and a glowing outline. \u00a0Under the “just add your commands to this display list” approach, each object has to render all of its geometry at once. \u00a0This meant that I couldn’t (for example) draw the background portion of the cursor early, and the glowing part later on; \u00a0they’d both always render at the same time.<\/p>\n
Another possible issue is that of rendering partially transparent objects. \u00a0These see-through objects are always a problem with modern 3D games, since z-buffers can’t be used to render them (z-buffers assume that everything is opaque, and so won’t allow you to draw anything behind a pane of glass, for example, if you draw the glass first). \u00a0The traditional way to handle these translucent objects is to sort them from back to front, then draw them in that order, after you’ve drawn all the non-translucent objects. \u00a0But with the simple-and-elegant way that I was handling drawing of objects, there was no way to sort the objects into any different order than they were already in.<\/p>\n
Anyhow, enough of the problem statement. \u00a0:)<\/p>\n
What I’ve changed is that renderable objects in VectorStorm are no longer given a pointer to the game’s vsDisplayList when it’s time for them to render. \u00a0Instead, they’re now given a vsRenderQueue object. \u00a0On that vsRenderQueue, they can provide their rendering instructions in one of several ways, and the vsRenderQueue can then reorder the drawing as required, to make sure that (for example) the glowing and transparent parts of objects are drawn last, while their opaque portions can still be drawn earlier.<\/p>\n
The other change is that vsLayer is now completely gone. \u00a0Instead, we now have vsScenes, which work very much like vsLayers did; \u00a0they’re just collections of renderable objects. \u00a0Like before, your game can have any number of vsScenes, and they’re rendered in order. \u00a0Right now, they share a single z-buffer and render target between them all, but setting it up so that the different scenes can have separate renders is certainly possible in the future, if I ever need that feature.<\/p>\n
You can probably tell by how I’m gushing, but I’m absolutely thrilled and relieved to have this all working at last. \u00a0Lots of stuff in MT2 (particularly the very old code) is currently working via a “compatibility” mode that I’ve put in the vsRenderQueue, and I do still need to convert those bits of code over to using the new systems instead. \u00a0But this change has illuminated a whole bunch of unreliable rendering code that was lurking in the GUI systems until now, and the stricter system should keep me from writing terrible code again in the future.<\/p>\n
Right now, these changes are only in my MT2 development branch — they haven’t been propagated back into trunk, largely because I’d probably have to make a lot of big adjustments to the testbed apps to make them render under the new systems, and I’m feeling like taking a bit of a rest, after this ten-hour coding session. \u00a0But I’ll update trunk sometime in the foreseeable future, and will post about it when I do.<\/p>\n","protected":false},"excerpt":{"rendered":"
Today I spent the whole day doing just one thing: \u00a0a major restructuring of VectorStorm’s rendering architecture. \u00a0This is, without a doubt, the biggest change to how rendering works in VectorStorm since I first wrote it. What you’re looking at in this screenshot is a not-yet-activated starting point, being rendered as a glowing outline, behind…<\/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,24,25,3],"tags":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/po9WK-ok","_links":{"self":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/1508"}],"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=1508"}],"version-history":[{"count":0,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/1508\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media?parent=1508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/categories?post=1508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/tags?post=1508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}