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

• hilite : 189 instances
• hilight:  103 instances
• highlight (the correct spelling):  3 instances

One of which was this:  ”float m_hilightLength; // how long is my highlight?”

And to think that I thought I was a stickler for spelling in my codebases!  Fixing it now.  :)

© 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

Most notable new visible change is that you can now move any object around the MMO world just by clicking on and dragging it.  This includes buildings, PCs, NPCs, and monsters.  (Previously, you could only move buildings, and you had to activate a specific tool button to do it;  now it happens by default when you try to drag an object in the world).

This means that you can (for example) grab any PC and drop him into a field of monsters, or into the middle of a wide lake, or etc.  It also means that you’re no longer completely reliant on the your AI devs to place monsters for you;  you can now manually move monsters around to wherever you want, whenever you want.  If you don’t want to, though, the AI devs will still do it for you automatically.  (TODO:  devs don’t currently like it if you grab a monster out of their grip;  they’ll fight you for control of it.  Need to make the devs gracefully release a monster if you grab it from them)

© Trevor for VectorStorm Blog, 2010. | Permalink

I’m also thrilled to have the mountainous region boundaries back.  I lost them for a bit after converting to the “paint-on” terrain interface, but I’ve got them back again now!  The player can use the brush tools to make the mountainous areas at the borders of each region wider, but cannot actually remove the mountain borders;  they’re permanent fixtures of the world.  Eventually, there’ll be a type of building you can place to make a small pass through the mountains, to allow subscribers to travel from one region to another.

But neither of those were really important fixes;  just little visual touches that I was glad to get in.  I also got a good start on some more game mechanics.

In the screenshot here, the big pillar in the background marks what I’m currently calling a “Grinding Zone” (suggestions for better names are welcome!)  Basically, you place one of these to tell your developers that you want there to be monsters to fight in that general area.  You will be able to (but cannot yet) specify how big the area is, what type of monsters should be there, what levels they should be, and how many you want.  Once you have “Grinding Zones” placed, subscribers will go to them when they want to fight monsters.  Alternately, you can use them as destinations for hunting quests, to force your poor subscribers to defeat twenty spiders and then return.

© Trevor for VectorStorm Blog, 2010. | Permalink

Also today, massive changes and bugfixes to lots of things under the hood.  Notably, fixes to rendering of text-edit-buttons, fixes to text entry (you can enter punctuation, now!  And more than 32 characters!), added functionality to the vsBox2D and vsFont, and a couple other minor bits and bobs that will eventually find their way back into the trunk VectorStorm library.

But the fun stuff is that I made it so that the action bars can be placed either vertically or horizontally;  I’m thinking about using them instead of the old-style build toolbars that you’ll remember from earlier screenshots and versions of MMORPG Tycoon.  In this screenshot, I’ve selected a quest giver, which has opened up a quest editing action bar on the left, where I can select any of his five current quests.  Right now, I’m looking at the one labelled “Q4″, which is a fetch quest.  So far, the player can edit the quest name and description, and add quests to the QuestGiver’s list (by clicking the little ‘+’ button).  All of these new functions are being performed via the (relatively) new scripting system;  each button in the actionbars just sends a text command into the scripting system, which takes whatever action is required.  This approach really is an awful lot nicer to to write and maintain than the “every button is a different class which holds its own game logic” approach which I was using in previous versions!

But I’ve derailed myself;  I was talking about quest editing.  Right now, the actual tasks which must be performed to complete each quest are still being procedurally generated, rather than actually being settable by the player.  But I’ll get to that tomorrow.  :)

Also on the radar: I’ve been thinking about getting rid of the “context matrix” in the top right corner of the screen, which shows actions you can take on a selected object.  It just uses up too much screen space, and I think it would work every bit as well (and without intruding into the screen nearly as much!) as a simple action bar.

© Trevor for VectorStorm Blog, 2010. | Permalink

Also today, I noticed that I was frequently getting crashes after placing a few buildings and roads.  I eventually discovered that the problem was the monsters – they were noticing when they were placed too close to a road, and were registering jobs for developers to move them into better positions.  This was old code left over from v1.1, and I was thrilled to see it still working.  Well, mostly working.  They were registering the position they wanted to be moved to in world-space, whereas everything is now running relative to the region it’s currently in, and so they were giving the developers bad positions to move to.  (It’s a bit like telling someone where you are by telling them how far you are from the edges of your map, when you’re looking at world map, and the person you’re talking to is looking at a city map — the positions on the map aren’t going to line up properly!)  Once I fixed that problem, they’re working again.  Place a road, and developers automatically move any nearby monsters away, to keep the roads relatively safe.

Not bad for code that was originally written back when the game was entirely made of 2D vector graphics.

© Trevor for VectorStorm Blog, 2010. | Permalink

Second, I brought back the “subregions” concept, where each region is divided into lots of smaller regions.  Last time I tried this, those smaller regions had full terrain definitions, and blending between those terrain definitions was painfully slow while building the terrain.  I’ve simplified that a lot, so now the subregions only specify a height, and that height is blended between the subregions.  It gives the terrain a nice non-uniformity, I think.  (If you view the full-size screenshot, you’ll see some blue vector lines;  those are showing the borders of the subregions)  But more than that, I’m wanting to try using these subregions as quest zones;  the player doesn’t actually create the quest zones — instead, he merely configures what should be in them and then has quests send subscribers into them.

Third, I fixed a number of terrain bugs, the worst of which was causing subtle incorrect behaviour at the north ends of regions, and some wasted CPU time everywhere else.  I also fixed a problem where a region boundary passed within 100 meters of a heightmap border, but didn’t cross that border;  it left a nasty gap in the mountains.  That’s now fixed as well.

Next step is going to be placing NPCs, and then the quest-making interface.  Hope to get most of that done tomorrow.  Crossing fingers!

© Trevor for VectorStorm Blog, 2010. | Permalink