So there’s a major VectorStorm engine update that’ll be happening sometime in the near future;  it’s really needed for MMORPG Tycoon 2 (and any other 3D games I might feel like doing in the future).

Here’s the thing.  VectorStorm 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.  One example is its render management.  VectorStorm organises a game into a series of “layers”.  Each layer is drawn in front of the previous layer.  Now, 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.  Within a layer, you couldn’t really predict how things would overlap.  So 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.

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.  Since 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;  the video card handles that for me.  Instead, I really want to draw according to whatever will allow the 3D card to render the game the most quickly.

(...)
Read the rest of Everywhere I look, Matrices! (783 words)

© Trevor for VectorStorm Blog, 2010. | Permalink

I’ve also uploaded the first new binary builds of those testbeds for the first time in ages.  The last build was of version 164 — this new one is version 1175.  The games themselves aren’t any different, but this now has the “ATI shader” fix which should have modern ATI cards able to use bloom and other shaders.  If you want to have a look, the link is in the sidebar, under “VectorStorm testbed games.”

If you’re interested in seeing the source code for the game library that I’ve written and use for all my games on this site, the source is publicly available under the terms of the GPL.  Details are on the page for the testbed games.

Now, back to MMORPG Tycoon 2 development!

© Trevor for VectorStorm Blog, 2010. | Permalink

Notable changes:

• vsMaterials are now very important.  Previously, they were a novelty, now they’re a core concept in the VectorStorm library, completely replacing the old “DrawMode”, and mostly supplanting direct setting of colors in display lists.  Materials are now loaded from data, instead of being specified in code.
• The bloom effect is much more subdued than previously.  This is largely because of work I’ve done in MMORPG2 to make there be a smaller visual difference between bloom-enabled and bloom-disabled builds.
• Added full lighting/fog/etc shaders — the same ones (currently) being used in MMORPG Tycoon 2.
• vsOverlays are no longer supported.  They were cool and quirky, but they really don’t fit in with the new focus on performance.

© Trevor for VectorStorm Blog, 2010. | Permalink

Here’s the list of improvements:

2D Display lists now correctly calculate their bounding boxes, even if there are transforms applied within the display list.  (previously, transforms within a display list were ignored for the purposes of calculating their visible size.  This probably wouldn’t have affected anyone;  it’s pretty unusual for a transform to be explicitly placed inside a display list that cares about its bounding box.

Bitmap font rendering now uses a vsBuffer to store each font glyph, so their data is stored on the GPU persistently, instead of needing to push explicit vertex positions and texture coordinates into the display list to draw text to the screen.  As a result, font rendering commands now only take up about a third as much system memory as they used to.  (My MMORPG Tycoon example was the string “Monster Type”, which dropped from requiring 1232 bytes of display list data to draw under the old system, to requiring only 352 bytes of display list data now that it’s using vsBuffers to store its vertex data.)

As a quick reminder, vsBuffer is my wrapper around OpenGL’s concept of VBOs (“Vertex Buffer Objects”), which are designed to store blobs of frequently-used data on the GPU.  The vsBuffer will also transparently fall-back to OpenGL’s older “array” functionality, for folks whose 3D cards or drivers don’t support VBOs.   Today, I have implemented interleaved VBOs within vsBuffer.

The old way of using vsBuffer was to give it an array of positions or colors or some other data type, and then put a command onto a display list telling the renderer what to do with the buffer.  (For example, you might tell it to use one buffer as a vertex position buffer, and another one as a normal buffer, and yet another as a texture coordinate buffer, each storing one type of data about each vertex to be drawn.)  That old code will all still work.  However, you can now use the explicit vertex formats exposed by the vsBuffer, such as “PNT”, for vertices which specify a position, a normal, and a texture coordinate.  The vsBuffer places all these bits of data together into a single OpenGL VBO, interleaved for fast access.  You bind these interleaved buffers by giving a “BindBuffer” command to the display list.  When finished, you can either give an “UnbindBuffer”, or “ClearAllArrays” command.

I’ve also converted the vsMesh utility class to automatically use its internal vsBuffers in interleaved mode, when it can.  So if you were already using the vsMesh or the vsMeshMaker (as I do in MMORPG Tycoon 2), you’ll automatically get this improvement.

With that said, I only see a moderate performance improvement on my laptop, but every little bit helps.  And I’m reliably informed that on embedded systems (such as mobile phones) that having interleaved VBOs gives substantially improved performance.  And someday I might want to look into things like that, I suppose.

Anyhow, as is often the case with these sorts of improvements, I’ve done this in my MMORPG Tycoon 2 development branch;  these changes haven’t yet been migrated back into the main publicly accessible VectorStorm trunk.  But I’ll get to that eventually.  :)

© Trevor for VectorStorm Blog, 2010. | Permalink

#define vsClamp(a,min,max) ( vsMin( max, vsMax( min, a ) ) )

(modified for legibility;  C/C++ coders, no need to warn me about how painfully dangerous that code snippit is. )

You’d use it like this:

vsClamp(1, 0, 10)  -> 1
vsClamp(0, 10, 20) -> 10
vsClamp(6, 2, 3)   -> 3

Effectively, you give it a number, and then a minimum and maximum legal value;  the value that pops out of the other end is the original number, clamped to within the requested range.

But what I’ve just discovered is that about half of my code is actually calling this function like this:

vsClamp( min, a, max );

That is, it sandwiches the value to be clamped between the minimum and maximum values.  Which actually makes a weird kind of sense, but isn’t how I actually implemented that function.  ”Oh no,” I thought, “all that code is going to be doing totally the wrong thing”

But as it turns out, calling vsClamp(  a, min, max ) is identical to calling vsClamp( min, a, max ), which is itself identical to calling vsClamp( min, max, a ).  As long as whichever value you intend to act as the ‘min’ is less than whichever value you intend to act as the ‘max’, all three are guaranteed to return the same result.

How bizarre is that?  :)

© Trevor for VectorStorm Blog, 2009. | Permalink

Multitouch surfaces (such as many modern laptop trackpads, iPhones, and other devices) are a little more tricky;  one could argue that they’re just multiples of the tablet “vanishing mouse”;  instead of one cursor that behaves that way, you have three or four of them.  Unfortunately, none of them are actually implemented that way in the OS, and the current version of SDL which I use doesn’t support these types of devices.  Well.. my MacBook Pro’s trackpad has a “two-finger-scrollwheel” feature which works in VectorStorm games, but only because it’s being treated as a scrollwheel.

Speaking of scroll wheels, it’s worth mentioning that under Windows and Linux, scroll wheels act like buttons.  They have integer “clicks”, and send a “button down” event every time they’re spun a distance of one “click”, however that’s defined for the particular mouse.  You can’t scroll by a half-click;  if you had a mouse which didn’t have ‘stops’ on it, and you spun the wheel by half of a ‘click’ (however far that is on that mouse), you’d get no scrolling at all.  By contrast, under Mac OS X, scroll wheels typically have no ‘stops’, and report a floating point distance.  The VectorStorm engine treats a scroll wheel as a digital button — that is, the extra precision available under OS X is lost.  Or to be more specific, SDL swallows that extra precision, and never shows it to VectorStorm in the first place.  Similarly, the current version of SDL does not support horizontal scroll wheels at all, either on the rare Windows mice equipped with them, or Apple’s “scroll ball” on the Mighty Mouse or two-finger scrolling on trackpads or touch-scrolling on the Magic Mouse.  SDL does support tilt wheels, which while still somewhat unusual, are no longer considered exotic under Windows.  On tilt wheels, the left and right tilting of the wheel shows up as two extra mouse buttons, and so can easily be mapped to functions inside VectorStorm.  I imagine that proper support for horizontal scrolling is probably going to require a new version of SDL, and even then, it probably won’t support full-resolution scrolling  under OS X.  And even if full-resolution scrolling was supported for OS X, I couldn’t actually use it for anything important, as Windows and Linux users wouldn’t have access to it, as it’s not provided at an OS level for them.

Most popular custom controllers like Guitar Hero guitars and Dance Dance Revolution mats are easy to support;  they’re just joysticks without the sticks.  If you can get your OS to detect them as gamepads, VectorStorm should be able to make use of them.

Gesture controls are, of course, big business these days, and every platform does them slightly differently.  But when you come right down to it, gesture controls are the first big thing that really doesn’t fit well into the VectorStorm input model.  Oh, sure, I briefly ported VectorPhysics (from the testbed apps) over to the iPhone, and used the accelerometer to set the gravity for the simulation.  But I couldn’t use SDL to get at the data, and passing the data through the sysInput interface was a real kludge;  sysInput is designed to handle one-dimensional data.  Passing matrices and 3D vectors through it was just awkward and unpleasant.  I don’t expect to see SDL providing support for these any time soon.

And things like Microsoft’s Project Natal would be even more difficult to shoehorn into my current input model, which was relying on all input forms being, at a certain level, exactly the same, as they have been pretty much from the Atari 2600 up until the Wii, with only very minor evolutionary adjustments a few times per decade.

© Trevor for VectorStorm Blog, 2009. | Permalink

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!

© Trevor for VectorStorm Blog, 2009. | Permalink

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.  :)

(...)
Read the rest of On Optimisations (623 words)

© Trevor for VectorStorm Blog, 2009. | Permalink

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

© Trevor for VectorStorm Blog, 2009. | Permalink

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.

© Trevor for VectorStorm Blog, 2009. | Permalink