So I borrowed a couple of gamepads from various friends, and have been spending the morning fixing VectorStorm’s gamepad support, and have reached what I consider to be “stage one” support.
“Stage one” support is that the system is set up correctly to work with an XBox 360 gamepad by default, and the Preferences game mode (or menu option, in the ‘Game in a Week’ standalone games) has a ‘Gamepad’ screen where you can configure the controls onto any gamepad controls you like. Note that your gamepad is calibrated at app startup time, so you might end up with miscalibrated joystick axes if you’re holding the joystick in a direction when the application starts up. This initial automatic calibration step was required in order to identify ‘trigger’-type joystick axes which center at -1 or at other strange points.
“Stage two” will be coming next, which will store control mappings separately, based upon how a gamepad identifies itself to the system. By this I mean that if your gamepad identifies itself sensibly (many do, some don’t), then VectorStorm will store that gamepad’s configuration automatically, and will then automatically recognise that particular gamepad in the future and re-load its custom configuration data. This will make it much nicer, swapping between various gamepads. I’m hoping that stage two will also add support for hotswapping controllers during gameplay.
I haven’t yet rebuilt any of the binary builds with this (I’ll probably wait for “Stage two” before I spend time migrating the changes around between all the various build branches), but there should be new versions of everything, with fixed gamepad support sometime tomorrow).
Yesterday I talked a bit about how much time I had lost, trying to extend VectorStorm’s collision system to support colliding bounding spheres against line segments, when I really should have just hardcoded the particular boundaries I wanted things to be restricted from crossing.
Today, I’m singing a different tune; I tried my hand at it again, and have had success! This dramatically simplifies some of the Munchers code, as it means I can simply drop collision lines into my collision scene, and have objects automatically react to them in reasonable ways, without spending time coding each one individually. This should actually save me a lot of time, and let me put a good deal more into Munchers than I had originally expected.
The down side, of course, is that I still don’t have a first playable version. That’ll be tomorrow, I suspect. As long as I get that first playable version of the game before Sunday, I’ll still be doing better than I did with Damsel!
Wow, that went a lot faster than I expected. I finished all of the tasks I laid myself in the last post, and so VectorStorm can now lay down areas of color by using a combination of a VertexArray command to specify vertices, and a TriangleStrip or TriangleFan command, specifying the order in which to use the vertices.
In this case, I’m using a TriangleFan to fill the asteroid, and a LineStrip to outline it. And it looks even better than I’d been hoping. I feel reassured that this isn’t going contrary to the “vector graphic” aesthetic; it’s just taking the overall look further along in the same direction it was already going.
VectorStorm is already a somewhat idealised version of vector graphics. That is, it’s taking the principles behind real-world classic vector graphics hardware, and is pushing a little beyond what ever actually existed.
For example, VectorStorm supports hardware-accelerated transformations. It allows blending between two different colors along the length of a vector. And it supports rendering ‘points’, which are not lines at all. No real vector graphics system (at least, that I’m aware of) has actually supported these features.
So I’m thinking about going further with it, based on the things I wanted to be able to do in Damsel, but couldn’t. And first among these is the ability to lay down solid areas of color, rather than solely lines. This would have helped distinguish between grass and road, without the need to draw huge outlines, which are functional but not particularly attractive.
In order to lay down areas of color, I’ll need to add a way to draw filled triangles. (Do I want to make them opaque triangles, like in normal 3D games, or should I stick with additive, as in traditional vector graphics? Opaque lets you use a lot more techniques, such as layering.. and you’d be able to easily do things like have asteroids block the stars in the background, by filling it with black triangles.. but additive is more accurate to the methods used to actually draw on a vector-style screen. Will need to consider this)
To implement triangle rendering, I’ll need to take a few steps.
- Need to extend fsFile to be able to cope with multiple-line commands, instead of requiring each command to fit onto a single line.
- Using these multi-line commands, extend the vsDisplayList to also accept vertex arrays and then implement indexed vector rendering commands referencing those vertex arrays (”MoveToIndex”, “LineToIndex”, etc.)
- Update fsFile to be able to cope with variable-length commands, instead of requiring a fixed number of arguments for each command.
- Use the variable length commands to add a new vsDisplayList command: “LineStrip i1 i2 i3 i4…”. This will let me remove a lot of optimisations from the vsDisplayList rendering of ‘MoveTo’ and ‘LineTo’ functions, by defining explicit strips directly in the data files.
- With all of the above working and in place, add triangle rendering commands referencing the same vertex arrays (”Triangle i1 i2 i3″, “TriangleStrip i1 i2 i3 i4…”, “TriangleFan i1 i2 i3 i4…”, etc)
So I’ll be poking with this stuff for the next couple of days. I’m hoping to have it all working by sometime early next week, though I only have limited time to work on it. Guess we’ll see how I go! 
As is often the case, the actual problem turned out to be pretty silly; one of my offscreen buffers was set to GL_NEAREST instead of GL_LINEAR during an important copy. Someone remind me again why I enjoy programming?
This still isn’t ready to go live yet; there are too many computers out there which can’t handle OpenGL Shader Model 2.0, so I don’t want to force this effect on everyone (Also, it’s still a good deal slower than I’d like). So I need to write detection code and hook it up into the preferences system and everything. But at least it’s in the pipeline.
But not this week; I start on my first experimental “Game in a Week” tomorrow, so all my spare time is going to go into that, rather than into improving the general game engine. I’ll post further details on the “Game in a Week” project tomorrow. Hold on tight, it’s going to be a bumpy ride. 
Something very strange is going on with the bloom effect that I’ve been playing with, recently; here’s a really good screenshot of it. See how the glow seem to occur in little evenly-spaced circles along the length of the straight lines? That can’t possibly be correct..
Yay, shader debugging!
They say that bloom is the new lens flare.
So I said to myself, who am I to fight Them? I mean, what with Their black helicopters and mind control rays and everything, I wouldn’t stand a chance..
This is still a work in progress; the code is based on the algorithms discussed at Philip Rideout’s OpenGL Bloom tutorial; working with pixel shaders (”fragment shaders”) is entirely new to me, so I’m learning quickly!
The code is checked in to the subversion repository, but is not yet enabled. I need to set things up so that VectorStorm can figure out whether or not a particular computer is capable of doing this effect (requires a video card supporting OpenGL Shader Model 2), and if so, turn this on by default.. or if not, use the old renderer by default. Probably will require a little bit more work to set things up so that I can switch renderers while the game is running. I still refuse to display a “restart the game for your changes to take effect” screen.
And now, time to get to bed. It’s nearly 3:00am. Amazing how time can fly when you’re staring at glowy things.
