VectorStorm Blog

Inside VectorStorm, there’s a function vsClamp;  it looks like this:

#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?  :)

So I’ve been looking around at various input devices again, and pondering about how VectorStorm might support them.  Tablets and styluses and light guns are, of course, easy, as from software’s point of view, they’re basically just mice which have cursors which ought to vanish when their buttons aren’t being held down..  the VectorStorm engine can handle these quite easily right now.

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.

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?)