The major one is that now that full procedural objects are being baked together into a single mesh (instead of lots of individual sub-meshes), the process of optimising those super-meshes was very slow.  The worst-cast situation at the moment is undoubtedly the starting area building, which is made up of about 600 triangles in total, or 1800 vertices, before being optimised down for rendering.  (I know, this doesn’t sound like a lot of triangles or vertices.  But due to its focus on procedural geometry, MT2 has to do a lot of model processing during runtime which other games can do outside of the game)

Optimising these procedural models mostly consists of checking all those generated vertices, to see if any of them are close enough together to be  merged together.  This means that for every element in the list, you need to check it against every other element in the list.  And when you have 1800 vertices, that’s an awful lot of checking.  Computer science folks call this O(n^2).  I just call it “really, painfully slow”.  Building that model freezes MT2 for about three seconds, on my computer.

What I’ve done is to add a simple cell structure to the mesh optimisation step.  Basically, imagine that the model is being built inside an 8x8x8 grid of cubes.  This way, vertices don’t have to be checked against every other vertex in the model — they only need to be checked against other vertices which are located in the same cell that they are.  This optimisation has sped up the creation of the “starting point” model from about three seconds to about half a second.  Which is still much too long, but it’s an awful lot better!  I’m going to have to think more about how to improve the speed further.

© Trevor for VectorStorm Blog, 2010. | Permalink

I love generic systems that just work the way that you’d expect them to.  :)

© Trevor for VectorStorm Blog, 2010. | Permalink

What you’re looking at in this screenshot is a not-yet-activated starting point, being rendered as a glowing outline, behind a tree.  Anyone who’s played with the MS1 build of Tycoon2 will know that one of the big rendering problems that it had was that glowing objects would often glow through opaque objects that were in front of them.  As you can see, this is no longer the case.  VectorStorm now automatically ensures that objects are drawn in the correct order, so you won’t incorrectly see obscured glowing effects.

To do this, I had to (warning:  the rest of this post contains dangerously boring technical details) change how VectorStorm renders.

Originally, VectorStorm was designed for rendering simple 2D vector graphic games.  As such, it was designed with a system of “layers”.  Your game could configure how many layers it wanted to use, and register sprites or other objects onto any layer you liked.  Within each layer, objects were drawn in order, with later objects (or later layers) drawn on top of previous layers.  With 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;  the layers were really used just for putting objects under different cameras.  For 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.  When I added solid rendering for ThunderStorm, the layers worked really well to ensure that some objects would always draw in front of other objects.

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.  This was (in my own opinion) simple and elegant, and it was great for a while.

But now that VectorStorm is rendering in 3D, layers don’t really make sense any more.  We 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).

But the real problem is that we now often have objects which have different drawing styles within a single object.  For example, the cursor in MT2 (and MT1, for that matter) is made up of two parts;  a dark background, and a glowing outline.  Under the “just add your commands to this display list” approach, each object has to render all of its geometry at once.  This meant that I couldn’t (for example) draw the background portion of the cursor early, and the glowing part later on;  they’d both always render at the same time.

Another possible issue is that of rendering partially transparent objects.  These 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).  The 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.  But 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.

Anyhow, enough of the problem statement.  :)

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.  Instead, they’re now given a vsRenderQueue object.  On 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.

The other change is that vsLayer is now completely gone.  Instead, we now have vsScenes, which work very much like vsLayers did;  they’re just collections of renderable objects.  Like before, your game can have any number of vsScenes, and they’re rendered in order.  Right 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.

You can probably tell by how I’m gushing, but I’m absolutely thrilled and relieved to have this all working at last.  Lots 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.  But 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.

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.  But I’ll update trunk sometime in the foreseeable future, and will post about it when I do.

© Trevor for VectorStorm Blog, 2010. | Permalink

The problem is that this geometry is made up of lots of hierarchical objects.  These rough tree models, for example, each contain about 40 or 50 individual objects;  one for every branch.  This means that each tree model ends up submitting about 40 separate batches of geometry to the graphics card.  Clearly, the thing to do was to merge all of the geometry down into a single blob which could be sent all at once.  The trouble was figuring out how to actually do that, within the confines of the VectorStorm library.

Well, it took a bit of doing, but I finally worked it and implemented it today, and the difference is stunning.  Compare the length of the green timing bar in this screenshot against the one from before these changes, to see just how much of a difference it’s made.

In theory, I could make it even faster by drawing these trees as instances;  in effect, telling the video card “draw this object in these two hundred places”, instead of telling it to “draw this object here” two hundred times.  A subtle distinction, but an important one for optimum performance.    I imagine that I’ll eventually need to do that.  But for now, this is a huge boost in speed;  I’m really pleased with it!

© Trevor for VectorStorm Blog, 2010. | Permalink

First thing: Yes, I finally have my Internet access back (yay!), and it’s faster and nicer than ever.  Imagine my surprise to find that in my absence, this web site had successfully weathered a storm of traffic caused by a mention on rockpapershotgun.  Also imagine my surprise to find that spambots seem to have become more devious over the past week, and after attempting to post spam comments, they then proceeded to post irate and abusive complaints about how their spam comments weren’t being posted.  (Yes, even the irate complaints were automatically flagged as spam.  And no, I didn’t click on the SEO links that they were peddling).

Second thing:  As I mentioned earlier, I’ve been doing a fair amount of development over this period without Internet access.  This development included both work on MMORPG Tycoon, and some design and development on another game.  This second game is intended to act as a bit of a safety net;  it’s a much smaller and more well-defined game than MT2, and is targeted at the iPhone/iPod market.  The hope is that if I do run into employment difficulties in the future (and I want to reiterate that I’m still doing just fine at the moment), then I could quickly transition into app store sales to hopefully continue to make ends meet for a while.

Third thing:  During this time, I also completed the single player campaign of StarCraft 2.  I don’t know that I enjoyed it, really, but I did finish it.  Which makes StarCraft 2 only the second RTS game which I’ve played all the way through in single player.

© Trevor for VectorStorm Blog, 2010. | Permalink

On the plus side, this current lack of network means that I’m not being tempted to browse the web or play StarCraft 2 instead of coding, and so I’ve been getting rather more than usual accomplished over the last few days. Not going to talk about it too much here; touchscreens really aren’t great for blogging. But once September rolls around and I can post more normally, I’ll have plenty to drone on and on about. And I might have a few more little updates between now and then. But no screenshots until I’ve got the internet back.

In other news, paying work is still rolling along, despite my last post. It’s looking a lot less bleak now than it did last week, so don’t worry about me too much; While we’re not completely out of the woods yet, I’m beginning to think that it’s all going to work out in the end. Further news if/when it’s warranted.

© Trevor for VectorStorm Blog, 2010. | Permalink

But enough of that gloomy topic — time for a unicorn chaser.  Look, it’s VectorStorm running on an iPad! (And also on the iPhone, not pictured here)  Long-time readers may recognise this as the “Testbed” program from the main VectorStorm library (with the orbiting lights moved closer in, to be easier to see).  There’s still a lot of work to be done on this port (which I’ll eventually do), mostly for supporting textures and audio.  But I was really pleased with just how easy it was to do the bulk of the port.  It was a lot simpler than the last time I did this, back when VectorStorm only drew lines, and rendered everything using OpenGL’s “immediate mode” rendering.

Also unlike last time, this time I did the port without obliterating the PC and Mac version of the code, so it should actually be possible to commit this back into trunk and have games just automatically be able to run on all three platforms.  Of course, there’s a lot of work that would need to be done to actually release a game on iPhone/iPad, both technical (it’d have to support changing screen orientation, the iPhone 4 retina display, iOS4 multitasking, multitouch input, etc), and legal/organisational (setting up a company to use for publishing, etc).

No, there’s no chance that MMORPG Tycoon 2 would run acceptably on any of these devices (although you’d better believe that I’m going to compile and run it once, just to giggle at the terrible frame rate), but I might eventually compile up some of my older games, or potentially future “Game in a Week” titles, and put them up on the App Store just to see what happens.

© Trevor for VectorStorm Blog, 2010. | Permalink

• vsMeshMaker no longer needs to specify the number of triangles in a model, before you start specifying those triangles.  Means that it’s really easy to just toss triangles in without thought, and have it come up with an optimised model at the end.
• vsMesh can now output vsFragments, instead of outputting vsDisplayLists.  If it outputs vsFragments, then the vsMesh may be deleted — all data storage is left in the vsFragments.
• MMORPG Tycoon 2′s procedural geometry algorithms now all use vsFragments, instead of vsDisplayLists.  However, they keep the vsMesh objects around, for ease of editing and ease of collision detection.

The next bit that I need is probably a way to merge two vsFragments together (with an optional transform applied).  This change would allow me to accumulate all of the geometry in a model into a single object, for rapid rendering.

For example, the trees in the earlier screenshots were each composed of about 30-40 objects, one for each branch and sub-branch.  While this is great for a lot of things, it’s an awfully slow way to render the trees — really, I need to bake all of those vertices down into a single object, and then just render that.

© Trevor for VectorStorm Blog, 2010. | Permalink

Anyhow.  I’ve been thinking a lot more about how best to set up MMORPG Tycoon 2′s world building.  The more I think about it, the more I’m starting to realise that thinking about “buildings” is probably too large-scale;  that really, the player shouldn’t be placing “inns” and “taverns”, but should instead be placing “innkeepers” and “barkeeps”.  The buildings themselves are kind of immaterial;  the important thing is the NPC who provides a service.

Or to put it another way:  There’s nothing special about the auction house in Stormwind, except that that’s where the auctioneers are.

Yes, the buildings do need to be there for graphical reasons.. but maybe there shouldn’t be distinctions between “Inn” and “Tavern” and “Weapon Shop” — there should just be a variety of buildings to pick from, and instead you’d have Innkeepers and Shopkeeper NPCs, and the PCs would seek out those NPCs the same way that they currently seek out particular types of building.

Pro:  More like real MMORPGs.  Means that different parts of the world can look very different, since we’re not forced to have the same model for an “inn” everywhere.  Makes it less damaging to the game to let players build their own buildings in some sort of editor, which would really let players be extra-creative in their world-building.

Con:  Makes it much harder to see how services are laid out in a town or city, since the functional pieces would be very small (and probably difficult to distinguish) NPCs, instead of being very large and iconic buildings.  Probably means that I’d need to model building interiors, so there’d be somewhere to place the NPCs.  After all, it would probably be weird for a shopkeeper to stand around and do business just outside his shop.  On the other hand, there are plenty of real MMORPGs where vendors just stand around on plinths;  shops aren’t always (or even usually) located inside buildings.

© Trevor for VectorStorm Blog, 2010. | Permalink

This isn’t going to be appropriate for the final trees — it’s way, way too slow to render (just look at the length of that green bar!  Though to be fair, there are 200 trees being rendered)  Here, each branch is effectively being treated as a separate object, instead of treating the tree as just one big thing.  Once I’ve pretty much settled on a tree generation system, I’ll set it up to bake all the geometry into a single object, instead of having it all in dozens of separate objects like this.

But I think that the general shape is reasonable.  Next step is going to be generating foliage for the trees.  And maybe at least making the trees brown or something, instead of having them appear to be made out of white plastic, as they do in this screenshot.

© Trevor for VectorStorm Blog, 2010. | Permalink