VectorStorm Blog

Just a quick note that yes, I’m still alive and kicking.  Been a little distracted by various non-coding things, but have fixed up a few more rendering issues.  Most notable new stuff is that we no longer waste time drawing terrain triangles which would have been drawn beneath the water (since the water surface is opaque), and some optimisations to my VBO implementation, which gives faster rendering overall (substantially faster, on my laptop).

I’ve also gotten a start on GUI stuff for MMORPG Tycoon 2, but that’s still in a very early state.  Hopefully there’ll be new things which can be screenshotted and posted within a few days!

Apart from all that, I’ve also been enjoying Ghostbusters: The Video Game far more than it deserves by any objective game review criteria, been watching re-mastered episodes of classic Star Trek (which aren’t quite as cringe-worthy as I’d expected them to be), and listening to JUMPsplat.

So it’s been an extremely busy day today.  Today I revamped a lot of VectorStorm’s underside, in order to support this magical feature that I’ve been wanting for a while;  the ability to do the old style “bright vector glow” at the same time as rendering other geometry normally.  Long-time readers will have noticed that all glow vanished from the MMORPG Tycoon shots a month or two back, as I simply wasn’t happy with the “brightness threshhold” mechanism I was using to determine which bits of the screen glowed and which didn’t.  Now I have a system where I can mark any individual object as glowing or not, and it works (basically) as one would expect.

Notice, for example, in this screenshot that the red hook object is made up of stripes;  half the stripes are brightly glowing white, and the other half are non-glowing red.  Notice that the cursor outline glows, but the sky and clouds (which are both brighter than the cursor outline) are not glowing.  This sort of trick is surprisingly tricky to do!  But I’ve finally got it working, and at virtually no performance penalty.  (In fact, in MMORPG Tycoon the glow will be cheaper than in previous games, as the lack of a flat black background means that I can get away with using a slightly cheaper Gaussian blur to generate the glow effect;  the background noise helps hide the extra artifacting)

I’ve also fixed a more low-level performance bug which was causing VBOs to take about twice as long to render as they should have.  Nice speed boost, and it means that I can use VBOs again, instead of using display lists for everything!  Yay!

There’s an old maxim amongst programmers, that premature optimisation is the root of all evil.  Or to put that in a less glib way, it’s generally a bad idea to perform optimisations before your program is completed, and it’s always a bad idea to perform optimisations if you have no way to check your performance before and after.  In practice, this means that you need to use a profiler before you start thinking about performing optimisations.

So apologies, but it’s another technical post.  For those who aren’t interested in programmer topics but are looking for pretty screenshots or discussions about game design, please feel free to skip this one.  Coders, hit the ‘Continue Reading’, below.  :)

Continue reading “On Optimisations”

After all that time fixing and re-fixing VectorStorm’s 3D engine stuff during the development of Lord, I just found yet another whopper of a bug in VectorStorm’s 3D projection matrix (the projection matrix is basically used to ‘flatten’ 3D objects into a 2D plane so that they can be drawn to the screen) .  This one was causing everything to render stretched horizontally.. more stretched, the more widescreen the window was.

Mental note:  tan(halfFOV)*aspectRatio does not equal tan(halfFOV*aspectRatio).  (It’s so obvious when you write it out like that, innit?)

So I’ve got the difficult bit of my 3D cursor model working.  It works more or less as you’d expect;  it finds the spot that your (hidden) mouse cursor is hovering over, and zips off into the distance to point at that spot.  The current cursor behaviour is very much like that from the 1.1 development version of MMORPG Tycoon (so if you’ve played with that, you know the stretchy behaviour that’s being used here).  Of course, the very first thing I did with this new cursor was to point out the shading discontinuity which currently occurs on the border between world zones.  That’s been on my “to fix” list for an awfully long time, and I’ve still never gotten around to it.  Probably because it shouldn’t be difficult to fix, so it’s not a particularly interesting problem to work on.. but it’s always annoying to spot one of those when I’m thinking about taking a screenshot.  Maybe by putting it front stage like this, I’ll motivate myself to fix it sooner.

While I’m on the topic.. while I do like the visual interest generated by the foliage effect, it becomes totally invisible only twenty or thirty meters from the camera.  In this shot, the foliage effect is being rendered over absolutely everything in the scene (except for the hilltops in the far, far distance).. and you really don’t get any benefit from it beyond the two slopes in the foreground.  And the color scheme being used here really isn’t working for me.  I should really fix that up.

But I seem to have derailed myself.  The cursor picking is working, yay!  Now I just need to fix the visible cursor’s behaviour.  The real problem with the cursor’s current behaviour is that the cursor doesn’t try to orient itself to be visible from the camera;  that is, the cursor is still a flat 2D object, and depending on how you’ve been moving it around, it can quite easily end up with its flat side facing the camera.  It also tends to end up sitting directly on top of the ground;  really, I’d like to have it hover a short distance above the ground, and perhaps cast a shadow down onto the ground, to help really show where it is in the scene.  Finally, since it has to be visible so far off in the distance, the cursor model is actually about three meters long, which makes it absolutely massive on screen when you point at a surface which is near the camera.  So it’ll need to change its size dynamically, so that it won’t end up using half the screen when it’s pointing at the ground right in front of the camera.

Apologies; the following post is kind of technical.  Those who are uninterested in this sort of fiddly technical stuff can safely ignore this post;  it contains nothing at all relevant to game design. 

A bunch of work under the hood of the VectorStorm engine, the past few days.  It’s mostly invisible from game code, but produces better performance in general.

The first big change is that I’ve created a “vsCache” class, which can handle any sort of named, reference-counted game resource (textures, files, etc).  It’s trivial to create these for anything you might want to keep cached or otherwise reference-counted.  I’ve reworked both the “vsTexture” and “vsMaterial” systems to use the vsCache system.  The system is, generally, invisible from the game code;  you still create “vsTexture” and “vsMaterial” objects from code exactly as before, but now these objects look in the cache for existing data that they can piggy-back on top of, instead of always using up extra memory for something that might be a duplicate.  This basically means that if you create sixteen identical vsMaterials, you’re not actually storing sixteen copies of the data any more, but only one.

Building on with that change, materials can now be loaded from text data files.  To do that, you just create a vsMaterial, passing in the filename from which to load the material definition.  Again, if that file has already been loaded into the cache, the engine won’t actually load the file, but will use the one which had previously been loaded.

Finally, materials now compile themselves into OpenGL display lists, which really speeds up the process of changing from one material to another while rendering the scene.  (Still TODO is to consider trying to make the engine automatically batch materials together, so we don’t have to keep switching back and forth between materials.  With the number of polygons I’m pushing through with each material right now, this would probably be a lot more work than it’s worth, so I’m not going to do it unless something easy occurs to me)

I’ve also fixed a couple of engine bugs.  One annoying bug in particular involved how the file reading classes parsed unquoted strings, which caused some strings to vanish entirely before the game code had a chance to see them.  I’ve fixed this bug in each “Game in a Week” game since Robot Finds Ice Cream, and keep forgetting to migrate the fix back into the core VectorStorm engine code.  I’ll remember this time, I promise!

I’ve also added some facilities to make sure that singletons created by engine code are accessible by game code.  All I’ll say here is that the C++ standards are basically non-existant about how static templated data should work when statically linking libraries together (and this has caused problems for me in optimised OS X builds, in particular)..  so by pairing a hash table with RTTI information, I’ve created a mechanism to make the code do what I want it to, without relying on a particular behaviour from the compiler.  (This was a critical fix, in order to get the vsCaches working)

I’ve also fixed an infinite loop bug in the vsHashTable, if there was a hash table collision.  Silly bug, I’d overlooked it before just because I’ve never plugged enough data into one of these to make a collision happen, until now.  And to my knowledge, nobody’s actually played with that before;  it was just something I’d put together months ago while working on localisation support, which kind of fell by the wayside once the basics were implemented.

These engine upgrades and bug fixes are all in the MMORPG 2.0 codebase now;  they have not yet been ported back into the public VectorStorm engine repository.  But I’ll get to that within the next few weeks (once I’m really confident with them).

Also, I currently have about five essays about game design half-written.  I should really finish one or more of those, so I can stop boring people with these painfully technical code updates.

So I’m a little baffled.  With one very minor adjustment, suddenly my terrain rendering is flying at fantastic speeds.  Here is a shot of the terrain.  What you’re looking at here is approximately two square kilometers of land (the other two alluded to in the title are behind the camera).  For those who play World of Warcraft, two square kilometers is approximately the size of Elwynn Forest, and my vertex density is approximately identical to that used in World of Warcraft (I’m using one vertex every four meters).

Now obviously, there aren’t any trees or plants or players or any other props in this scene (actually, there is one prop in the scene, but it’s hidden behind the slope of the ground in the foreground.  Sorry about that), so it’s not really fair to compare rendering rendering speeds, but see the horizontal red and green bar in the bottom left corner of the screen?  That’s my information about CPU/GPU utilisation.  The little green part of the bar is how long this terrain is taking to render (the red part is waiting for vsynch).  This is much faster than I was expecting it to render, especially considering that I’m not performing any adaptive rendering to try to cut down the polygon count (check the wireframe inset;  the polygons are so dense in those distant hills that they appear to be being drawn solid!);  the code is just splurting all 262,144 vertices to the 3D card, lighting them in hardware, and drawing them to the screen.

I’m now left wondering whether I should bother with adaptive terrain mesh, or whether I should just go with this for now, and instead move straight on to fixing up the texturing of the terrain.

So as mentioned elsewhere, I’ve begun working on an update to MMORPG Tycoon.

MMORPG Tycoon was always about three things for me.  One was a game concept I had been tossing around for ages, called “Bunnies Can’t Die”.. up until Rayman: Raving Rabids came out and killed that title stone dead.  I’ll talk more about that project in some future post.  Maybe I’ll even post a screenshot, if I can dredge one up from somewhere.  But suffice to say that it was fundamentally about a game with lots of creatures on screen.  10,000 on screen at once, in fact.

The second thing behind MMORPG Tycoon was a question to myself:  Why do so many people get hooked on MMORPGs, when fundamentally there isn’t anything in them?  With the exception of small amounts of story, fundamentally you’re playing the same game over and over again ad infinitum;  why is it that people don’t get bored with MMORPGs the same way that they get bored with most other games, even though to a casual glance, MMORPGs seem to be far less interactive and much shallower than single-player games?  (I expect that I’ll explore this topic in a lot more depth in future posts)

The third thing (which I guess I kind of spoiled by the title of this post), was the challenge of procedurally generating a lot of content for a game;  not something which I’d done, before.  In the first release of MMORPG Tycoon, there was a fair amount of data procedurally generated at the start of each game;  your competitors and how well they were doing, the 10,000 potential subscribers in the game universe, the general map framework you had to work within, the initial map set up by the people you had ostensibly bought the business from, the initial set of classes and monsters and so forth.

For MMORPG Tycoon 2 (or whatever it ends up being named), I’ve been focusing on these second two parts, but am still in the early phases of both.  I’m slowly narrowing in on what I want the game to really be focused around, and I’m also slowly building up tools to procedurally generate all sorts of content.  So far, this content has mostly been 3D mesh for use in generating props, roads, vegetation, buildings, etc. on the fly.  No textures being applied to things yet, so it all has a slight “shiny plastic” look to it at the moment, but that’s only temporary.  The squiggly thing in the shot above is a decorative prop which the current game testbed generated for me a few minutes ago.. it begins to give an idea of the sorts of shapes that procedural mesh can create!

Anyhow.. this is really just a quick note to reassure everyone that I’m still alive and still working on things;  between illness and real world paying work, I haven’t been accomplishing much during home time, the last few weeks, but I’m hoping that both illness and work will ease up again soon.

I promise;  last post about lighting support!

Here we have fully working lighting support.  We have a shiny sphere, and a more matte (though still lit) cube.  The bright white spots represent lights in the scene.. though in this screenshot, they’re not colored the same as the light they’re emitting.  They’re just for debugging that light is actually coming from the right spots.  This is now all being done through the proper VectorStorm API, and while there’s still a fair amount of optimisation work to be done, it’s now functional, and optimisation work should happen entirely inside the engine, without requiring changes to client code.

With this tech in place, I’m now ready to resume proper game development again.  But more on that tomorrow!

I really do like to use $5 vocabulary words, sometimes.

Anyhow, this is just a quick note that I’ve got lights into VectorStorm.  There might be a few minor API changes to them from here out, but they’re now basically functional.  Currently supported are ambient, directional, and point light sources.. which should be all I ever need, really.  Last major thing required for full proper 3D rendering support is a materials system (currently, all 3D geometry is being drawn with a silly bright specular highlight that makes it look like everything is made of plastic.. look at the screenshot a few posts down to see that in action)  Last big thing to be done is the material system, so that different geometry can be marked as reacting to lights in different ways.  My current plan is to rip out color and texture support from the innards of the renderer, and integrate both of those into a single Material system.  Should simplify the code very nicely, I hope!

Actually, I suspect there’ll only be one more lighting post;  when the material system is finished and working and I have a screenshot and a demo program to show off, which would technically make this the penultimate post.  But I like the word ‘antepenultimate’ more, and it gives me a little extra wiggle room in case I run into problems.

Anyhow.  I’m going to go sleep now.  Am still mildly sick, so I’m going to try to get extra rest.  Chat with you all again in a day or two!