VectorStorm Blog

Old:

	float hw = width * 0.5f;
	float hh = height * 0.5f;
	// draw dark background
	vsDisplayList *list = new vsDisplayList(512);
	vsVector3D va[4] =
	{
		vsVector2D(-hw,-hh),
		vsVector2D(hw,-hh),
		vsVector2D(-hw,hh),
		vsVector2D(hw,hh)
	};
	int ts[4] =
	{
		0,1,2,3
	};
	int ls[5] =
	{
		0,1,3,2,0
	};
	list->SetColor(vsColor(0.0f,0.0f,0.0f,0.9f));
	list->VertexArray(va,4);
	list->TriangleStrip(ts,4);
	list->SetColor( vsColor::White );
	list->LineStrip(ls,5);
	list->ClearVertexArray();
	vsFragment *fragment = new vsFragment;
	fragment->SetDisplayList(list);
	fragment->SetMaterial( "White" );
	AddFragment( fragment );

New:

	vsBox2D box( width, height );
	box.Recenter();
	AddFragment( vsMakeSolidBox2D( box, "TestimonyButton" ) );
	AddFragment( vsMakeOutlineBox2D( box, "White" ) );

This is much nicer, innit? :)

Certainly it’s a lot shorter. Both create an identical box with an identical white outline. This is just using the new “vsMakeSolidBox2D()” set of functions which were recently added to VS_Primitive.h. I really ought to have more utility functions like these; they make it an awful lot faster to quickly prototype things!

This is mostly for the programmers in the audience.

In the VectorStorm library, I have a “box” class which represents a 2D or 3D box.  Currently, you initialise one of these by specifying the positions of two opposite corners.

For a long while, I’ve been thinking about adding the ability to just set the width and height of the box, rather than needing to explicitly set the corner positions.  This would be a whole lot more convenient for many uses.

The question is about expected behaviour.  If you wrote this code:

vsBox2D myBox(100,20);

Would you expect myBox’s horizontal corners to be at 0 and 100, or at -50 and 50?  (That is, should the box start at (0,0), or should it be centered on (0,0)?)

Anybody have thoughts?  I’m having real trouble deciding what the behaviour should be when specifying a box by its dimensions, instead of by its corner positions.  Maybe I should just avoid this question entirely by making people explicitly set the corners, and not allowing them to set the dimensions directly.

I have no idea what this image is.

I’ve made a bunch of little tweaks to the VectorStorm engine today.  Most notably:

When doing a scene update, the camera now updates last, instead of first.  Previously, the camera would pick where to be before the game had a chance to take any actions, which usually led to the game camera lagging one frame behind whatever it was supposed to be following.  (Of course, now you’ll have the opposite problem;  the game will no longer be able to tell where the camera is, since it won’t have moved into position until after the game finishes its update)  In practice, the real solution is for the game itself to take responsibility for updating the camera whenever is appropriate for that game.  But as a default, having the camera update last is usually less-bad than having it update first.  So I’ve changed it.

I noticed that vsFont wasn’t applying text colors to strings which were justified as “centered” or “right”;  they were always coming through as pure white.  This is now fixed, in current trunk.

I also added another “primitive” function for creating renderable textured rectangles (as vsFragments that can be attached to a vsSprite or vsModel), this time supporting tiled textures.  You can specify how big the tiles should be, and can optionally specify a rotation for the texture.  Check for vsMakeTiledTexturedBox2D() in VS_Primitive.h, for that.

I’ve also been poking with the bloom effect again;  I noticed that the trunk version looks pretty ugly at large screen sizes.  I think I have it balanced nicely again, but haven’t committed these changes to the public repository yet;  probably later tonight or tomorrow, once I’m certain that performance is still okay.

Finally, I’ve just finished scaling down the Asteroids testbed game.  It’s been misbehaving ever since I converted it over to Box2D, because its objects were moving too fast for Box2D to cope with.  So I’ve reduced everything by a factor of ten, and now things are moving at a reasonable speed again.  I’ll be checking that in a bit later on as well.  Oddly, I’m still occasionally having shots bounce off of asteroids, without receiving a collision callback.  Mind you, I’m using an ancient version of Box2D;  maybe I should update that someday.

I’ve just updated the trunk of the VectorStorm subversion repository with all the accumulated library changes from MMORPG Tycoon 2, Spratt 2, and GoGoGo!  So for any of you who are interested in all of that, it’s now live and publicly available.  Subversion repository details are on the Vectorstorm Test Games page.

I’ve also updated the pre-built binaries there (which while the text claimed to be from build ~1000, were actually linking to build 138.  Really, really old!), in case someone missed the old Asteroids game or VectorPhysics.

And as you can guess from the photo, I’ve finally brought the iPhone port into the public repository as well.  Note that to actually make an iPhone build of VectorStorm, you’ll need the usual iPhone developer credentials.

It’s worth mentioning that the testbed games are still all working via “compatibility modes” where the new systems try to act like the old systems, for the most part;  none of them are making proper use of materials, the render queue, VBOs, or any of the other new systems I’ve written to make my games easier to create and faster to run.  At some point I’ll go back through them and refactor their code to make them nicer and faster.  But that hasn’t happened yet.

First and foremost:  I’ve put up another update to GoGoGo!.  If you were having crashes or etc, go grab that.

Technical stuff follows:

In computer graphics, the scarcest resource is currently (usually) communication time.  That is, you only have a certain amount of time for the CPU to deliver data and instructions to the graphics card, if you want to maintain your frame rate.  These days, that communication time is far more of a limiting factor than how many polygons you’re going to draw or how many pixels you’re going to be touching.

Back in VectorStorm’s early days (say, up to about Game in a Week #5), I wasn’t actually drawing enough for this communication speed to be a big issue;  it was just a few dozen lines, for the most part.  I could just naively send them to the graphics card every frame.  Easy.  But as my games have started drawing more and more — triangle meshes, textures, etc.  It has begun to become more and more important to optimise the communication.

In OpenGL, the usual way to do this is with Vertex Buffer Objects (VBOs).  Basically, these are just a way to store data directly on the graphics card.  So instead of needing to send a hundred vertices to the graphics card each time you want to draw them, you can instead just say “Draw the hundred vertices that I already put into VBO #1.”  Much faster to transmit, that way!

The tricky problem, of course, is that OpenGL will typically need to be restarted in the new resolution, which means that all of that stored data on the graphics card needs to be sent up again.  And I was forgetting to do that for VBOs.

The funny thing is that this bug has been in the code ever since GiaW #6, and has affected several released games in the time since then.  It’s just that none of them have actually presented an interface which allowed you to change the screen settings while the game was running.

Anyhow, I have this fixed now.  Fullscreen and changing resolutions from the Options screen should all now be working again.

Similarly, the formatting issue on the Options screen was related to VectorStorm not knowing how to build a bounding radius around data which was stored inside a VBO.  Since it didn’t know how big the different pieces of text were, it didn’t know how to keep the different pieces of text from overlapping.  I’ve now fixed that issue as well, so the options screen is correctly formatted again.

Just goes to show how adding a single new feature (VBOs, in this case) can break a whole bunch of old things that used to work properly.

(Note to self:  Must fix textures to be re-uploaded to the video card when a resolution change happens, as well.  I’m getting away with not doing this right now because there are no textures in the game mode where you change resolution/fullscreen, but that won’t always be the case.)