Warning: \u00a0technical brain-dump post. \u00a0I’ll try to have something more interesting to non-techies tomorrow. \u00a0:)<\/p>\n
So there’s a major VectorStorm engine update that’ll be happening sometime in the near future; \u00a0it’s really needed for MMORPG Tycoon 2 (and any other 3D games I might feel like doing in the future).<\/p>\n
Here’s the thing. \u00a0VectorStorm was written to be a 2D game engine, and so some of the things in it aren’t exactly what you’d want for a full 3D engine. \u00a0One example is its render management. \u00a0VectorStorm organises a game into a series of “layers”. \u00a0Each layer is drawn in front of the previous layer. \u00a0Now, in a game like MMORPG Tycoon 1 where your game was entirely 2D, and you wanted to make sure that your UI was being drawn in front of your game map, and tooltips were being drawn in front of the UI, and the cursor was being drawn in front of the tooltips, “layers” is a really sensible way to arrange things. \u00a0Within a layer, you couldn’t really predict how things would overlap. \u00a0So if it was important that object “A” draw in front of object “B”, you need to put object A in a higher layer than B.<\/p>\n
However, in the world of 3D, we have depth buffers which handle this whole “what goes in front of what” thing for us more or less automatically. \u00a0Since MMORPG Tycoon 2 is a 3D game with a depth buffer, I mostly don’t need to draw things according to how they will overlap on screen; \u00a0the video card handles that for me. \u00a0Instead, I really want to draw according to whatever will allow the 3D card to render the game the most quickly.<\/p>\n
<\/p>\n
In practice, this means that I want to try to bunch things together — if I’m going to draw grass, I want to draw all of my grass all at once. \u00a0If I’m going to draw clouds, I want to render them all in one go, instead of setting each one up individually and rendering them one at a time. \u00a0You get the idea.<\/p>\n
What I’m setting up to do is called “material batching”; \u00a0it’s where everything using a particular material will be smashed together and rendered all at once. \u00a0 In MS1, rendering the terrain worked like this:<\/p>\n
For MS2, with material batching, I’m hoping that rendering the terrain will work like this:<\/p>\n
Since setting the materials is (generally) the most expensive step of rendering, making this change to set each material only once per frame should make VectorStorm run dramatically faster, especially on lower-end hardware. \u00a0But it’s not a simple change to make.<\/p>\n
What’s more, some types of materials really need to be rendered in a special order. \u00a0In a 3D game, transparent objects usually need to be rendered last. \u00a0In VectorStorm in particular, any glowing objects need to be rendered last (This isn’t yet being done — this is why you can see glowing objects through other objects in Tycoon2-MS1). \u00a0By drawing materials in batches, it’ll mean that I can have objects which have glowing parts as well as non-glowing parts (such as selected buildings, which have glowing outlines and non-glowing polygons), and draw the non-glowing parts at the start of rendering, and the glowing parts at the end of rendering, whereas in MS1, I had to draw all of an object all at the same time.<\/p>\n
Anyhow. \u00a0I don’t have this material batching system working yet, but it’s not far off.<\/p>\n
The first step was moving matrix building from the OpenGL shader to within the VectorStorm code. \u00a0Matrices are a mathematical construct which relate how one thing is placed with respect to another. \u00a0For example, in MMORPG Tycoon, each world region has a matrix describing where that region is in the world. \u00a0Similarly, each building, PC, and monster have matrices describing where they are in relation to the region that they’re currently inside. \u00a0And, of course, the player himself is little more than a matrix that you can turn and move around with the keyboard and mouse controls.<\/p>\n
It used to be that I used standard OpenGL calls to let OpenGL calculate all of these matrices for me automatically. \u00a0That worked great for the old hierarchical rendering code, but now that I’m getting ready to do material batching, I’ll need to know precisely where every object is, so I can render them outside of that hierarchical order. \u00a0Took me most of yesterday, but I finally got this all working properly. \u00a0Debugging broken matrix math isn’t a whole lot of fun!<\/p>\n
(Amusingly, at work today I also spent most of the day debugging broken matrix math. \u00a0And then I came home and played a little Super Mario Galaxy 2, which is using more matrices than I’d like to think about. \u00a0I think I’m becoming hyper-sensitive to matrices.)<\/p>\n
Anyhow. \u00a0Now that that’s done, the next step is to set up vsDisplayList to be able to transparently grow on demand. \u00a0In VectorStorm games, drawing commands are communicated from game code to the rendering engine via an object called a vsDisplayList. \u00a0Right now, you have to pre-declare how big you want your display list to be. \u00a0And then if you try to put more instructions in than you originally asked for, it generates an error. \u00a0And if you put fewer instructions in than you originally asked for, you’re wasting memory that could have been used for something else. \u00a0Allowing display lists to automatically grow and shrink as needed will make it much easier to use them, and should hopefully reduce overall memory usage as well. \u00a0Eventually, these growing-shrinking display lists will be used for building the material batches. \u00a0I’ve got this change about halfway completed now; \u00a0should be able to wrap it up tomorrow.<\/p>\n
Once that’s done, all that’ll be left to do is the material batching itself, and defining some way to specify what order materials should be drawn.<\/p>\n
Once that’s all done, the VectorStorm engine should (a) be faster, (b) be more flexible, (c) not have glows shining through solid objects, and (d) still be backwards-compatible with all earlier code. \u00a0It’s win\/win\/win!<\/p>\n","protected":false},"excerpt":{"rendered":"
Warning: \u00a0technical brain-dump post. \u00a0I’ll try to have something more interesting to non-techies tomorrow. \u00a0:) So there’s a major VectorStorm engine update that’ll be happening sometime in the near future; \u00a0it’s really needed for MMORPG Tycoon 2 (and any other 3D games I might feel like doing in the future). Here’s the thing. \u00a0VectorStorm was…<\/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\/so9WK-matrices","_links":{"self":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/1413"}],"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=1413"}],"version-history":[{"count":0,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/1413\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media?parent=1413"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/categories?post=1413"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/tags?post=1413"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}