VectorStorm Blog

So it’s been a bit of a roller coaster week (and technically, it’s not over yet!)  Lots of ups and downs, thrills and excitement while it lasted, but in the end, I’ve basically wound up right back where I started.  No change to the work situation;  it’s tough to find a paying position this close to the end of the year;  everybody has basically stopped hiring until after the holiday period is over.  Will keep trying, though.

In other news, I’ve successfully converted the latest VectorStorm engine over to the iPhone.  This photo is showing an iPad rendering the same graphics as are shown in the Mac screenshot a few posts down (though here zoomed in, and tilted a little).  Those keeping track will note that this is the third time that I’ve ported the VectorStorm engine over to the iPhone, but this is the first time that I’ve managed to maintain the ported engine’s compatibility with PC and Mac builds, so the port can finally be brought into the live engine trunk.  This means that any future games I make can easily be compiled for all three platforms.  (Earlier games would have to be updated to work with the newer engine.  That wouldn’t be a very big undertaking.)

Additionally, I’ve finally succeeded at getting VectorStorm’s texture loading+rendering to work;  I’ve never managed to wire that up on an iPhone or iPad before.  (Each of the visible white lines in the photo is a “scribble” texture.  In retrospect, this wasn’t the best way to show off this “texture-loading” feature.  But it’s the only comparison shot I have.)

There are, of course, some caveats to the iPhone port, as it’s not quite complete.  These still-not-working features are:

1. Haven’t yet reimplemented the sound or music systems for the iPhone, so no sound is currently supported on the iPhone.  (It won’t cause problems if you try to use them, it just won’t actually make any noise)
2. Currently will only track a single touchscreen point.  Games query this via the sysInput system’s mouse interface.  I need to add support for tracking multitouch, so that I can handle pinch-zoom and other gestures.
3. No proper interface for accelerometer data (there’s a nasty hacky way to get at that data, but since I’m not planning to actually use the accelerometer any time soon, I’m going to ignore this for now)
4. No proper handling of screen orientation.  I’ll need to figure out the right thing to do, here.
5. No support for shaders at all.  Even though the later iOS devices do support shaders, I haven’t set up VectorStorm to be able to decide whether or not to enable them under iOS.  For now, iOS is being treated as completely shaderless.  (It’s using the vsRendererPretty interface, rather than vsRendererShader or vsRendererBloom interfaces)

But it does support suspend/resume on devices which support that, and also supports the iPhone 4′s retina display.  Which is pretty neat to see in action.  :)

For those who are interested in graphics tech, there are also a few things which are disabled in the iPhone port, simply because OpenGL ES doesn’t support them.  These include setting different “blend functions” (proper support for subtractive rendering, for example), compiled OpenGL display lists, etc.  As with sound above, games which try to use these features won’t fail to compile;  those operations simply won’t be used.

I want to implement sound and music, and add support for multi-touch tracking.  Once that’s all good to go, I’ll pull all the recent changes to VectorStorm back into trunk.  (Sorry, Dan, I figured that it’d be better to wait and do the big trunk update all in one go, instead of doing it piecemeal, multiple times during a single week)

Here’s a screenshot that won’t excite anybody but me.

Can you spot the exciting thing?  It’s not the cylinders (which should hopefully be proper trees by the end of the day, but are as of yet still just cylinders waiting to be shaped) — it’s actually the little green horizontal line at the bottom left corner of the screen.

You’ve seen screenshots with that little green (and sometimes red or blue) line before.  It only shows up in my debugging builds, not on the builds that I release, and it helps me gauge how quickly the game is currently running.

The two vertical blue bars are markers.  If the horizontal line doesn’t reach the first blue marker, then we’re running at 60fps.  If the horizontal line passes the first marker but doesn’t reach the second blue marker, then we’re running at 30fps.  Beyond that, the frame rate is really low.

The exciting thing is that if I had taken this screenshot on this computer yesterday, that horizontal green line would have stretched all the way over to the first blue marker — we’re drawing in half the time that it took before, in this same situation.

See, the VectorStorm library has always been phenomenally slow at drawing bitmapped text.  And when the context matrix (the box in the top right corner) is open, it really would slow things down to an extreme degree.  And unfortunately, this was difficult to solve because the real problem was caused by the VectorStorm library’s fundamental approach to drawing.

Continue reading “A technical post”