VectorStorm Blog

Error:  Allocation from MMO_GroundClutter.cpp line 42 was allocated using new [] but was freed using delete;  should have been delete []!

I can’t say how proud I was to have had my memory management system be smart enough to print out such a cogent and useful error message.  I’m less certain about how bright an idea it was for it to do the correct thing after displaying the error, instead of crashing immediately.  This error message, for example, has been generated by the game for three days now, and I only noticed it today.  If it had crashed immediately, I would have fixed it at once.

For those who aren’t familiar with the pleasures of C++, a large part of working with the language has to do with requesting and returning blocks of memory (by which we traditionally mean RAM).  We use those blocks of memory to store data temporarily.  Textures, models, various bits of gameplay, etc.  In C, there was only one way to get a block of memory:  you called “malloc()”, passing in the size of the data block you wanted to receive.  And when you were done with that data block, you called “free()”, the same way.

In C++, for various reasons, two more methods were added:  ”new” (for creating an instance of a C++ class), and “new []” (for creating a lot of instances of a C++ class in a big array).  Because these different blocks of memory contain different data and are allocated in different ways, they need to be freed in different ways.  For “new”, you must call “delete” to release the object.  For “new[]“, you must call “delete[]“.  In many memory management implementations, calling the wrong one will cause your program to crash, so it’s important to get this right.

VectorStorm’s memory management system isn’t a fast one.  I should say that up front.  When a game asks for memory, the memory management system does a pretty dumb linear search through its preallocated heap space looking for a spare area that it can hand out.  It also isn’t very memory-efficient;  it allocates extra space before and after each memory block that it hands out, storing information about how the block was allocated, by which file and which line of code, as well as boundary guards for detecting whether something has accidentally written past the end of the block.

These things all make it possible to easily detect issues like mismatched allocation/deallocations, leaks, and other places where programs have accessed memory incorrectly.  So every time I make a mistake about these things (which thankfully isn’t very often), it’s there to poke me with a stick.

It’s worth also noting that VectorStorm’s memory management also isn’t friendly to devices which want to use virtual memory (i.e. almost every modern computer or phone), since it handles all its own allocations inside of its own huge data block.  From the OS’s point of view, a VectorStorm game uses only a single memory block, which is several megabytes in size.  (In the case of MMORPG Tycoon 2, it’s currently about 600 megabytes in size, and will eventually be even larger.  Most of my other games are in the 6-30 megabyte range).

Between it’s lack of speed and lack of friendliness toward virtual memory support (or fragmented memory in general on the target device, as is often the case on, for example, the iPhone), I expect that for any major release I’d swap over to using the regular OS-provided allocation/deallocation functions instead of VectorStorm’s built-in ones.  But for the purpose of development, it’s great having a system like this there to catch errors early.  I know from long experience that it can be a real bear to track these things down otherwise.

So I’ve finally settled on a new ground clutter appearance.  I’m really digging this.  It’s subtle, but just lends a bit of texture when you’re down low near the ground, but is soft enough that it completely vanishes once you’re only a little bit up into the air (which means that I can stop drawing it then).

I also noticed that the “Old” screenshot of ground clutter that I posted yesterday was the wrong one;  it actually showed the newer clutter models, just using a different sort of colour.  I’ve now updated the first screenshot in that “Ground Clutter” post to actually show what ground clutter looked like before.  Pretty dire, eh?

Now I’m trying to decide what to do with the mid-level clutter, which is the larger streaky stuff visible in the screenshot.  In my codebase, it’s called “edge clutter”, since it’s generated along polygon edges.  It looks pretty good from the air, but starts looking odd when viewed from down here.  Maybe I fade it out as you get down next to the ground, or something like that.

Plenty of stuff still to think about, I guess!

So I’ve been spending a little bit of time looking at graphical things again, as I mentioned a week or two back.  Today I finally turned my attention to “ground clutter”;  just little details that I add to the ground around the player, to try to keep the ground from feeling too terribly plain, when the viewpoint is low down to the ground.  In the screenshot here (if you view it full-size), you can see some of the old-style clutter.  It was basically just dark green triangles on the ground.

Also notice the little red and green line at the bottom left corner of the screen — that’s my profiling data which shows how long it takes to render the scene.  Now, in this case, I happen to be doing this bit of coding on an old laptop, so it’s actually running slower than it would on most modern PCs.  But it’s still worth keeping in mind when you look at the next screenshot:

Now, the first thing I’d like to mention is that this is “new-style” ground clutter, but I’m not yet happy with its appearance;  it doesn’t yet match the style of the rest of the world.  But there are a few notable points to bring up.  First, there’s twice as much of it.  In the first screenshot, there are 1000 pieces of ground clutter scattered around the player.  In this second screenshot, there are 2000.  Second, each piece of ground clutter is now made up of four triangles, instead of one.  So in total, we’re drawing eight times as many triangles as we were before.  Plus, these triangles now have textures on them (previously they were solid), and they have per-vertex color data, which was previously just a constant.

Now look at the profiling bar;  with eight times as much stuff going on, it’s being substantially faster to render.  Why is that?  Well, as it turns out, it seems that a lot of processing time for the first shot was going into making all of those triangles correctly face the camera, whereas with the new system, I don’t worry about that at all, and so don’t have to reprocess all of the clutter every frame;  I can just keep re-using it as long as the player doesn’t move around too far.

The real question from my point of view is whether I’ll be able to make this approach fit in with the general visual style of the game.  It doesn’t seem to be working too well right now, but I’ll keep trying.  I’m sure I’ll work something out.

Remember a few weeks back when I talked about how pleased I was to have fixed a bug involving vertex normals when welding together the vertices of models?

Well, it turns out that I hadn’t fixed it at all;  I’d merely hidden it in a few situations.  As you can see from the screenshot on the left, the problem was still visible in other places (left corner of the graveship, top of the column, and more subtly, roof of the inn).

I believe that I’ve now well and truly solved the problem;  certainly all those problem areas are now rendering more appropriately, as seen in the screenshot on the right.  So yay.  As I mentioned before, these fixes are in the “vsMeshMaker” utility class in the VectorStorm library.  These fixes will be brought into the live trunk sometime in the next few days, once I’m satisfied that the bug is actually fixed for real this time, and hasn’t just scampered off to hide under some different rock.

In other news, I spent a good half hour trying to figure out why I haven’t been able to post thumbnails of screenshots since moving to the new server.  Turns out that WordPress really wants to have php5′s gd module installed, and I had neglected to install that on the new server. Boo to WordPress’s support sites, which don’t mention that it needs this module.

In non-news, I’m still poking away at MMORPG Tycoon 2 and making (extremely) slow but steady progress.  There hasn’t been much to show for a while, as I’ve been re-plumbing its innards to use regular VectorStorm library functionality wherever possible, instead of using custom rendering code everywhere.   VectorStorm now supports out-of-the-box features (batched rendering, etc) which I had previously implemented explicitly within custom game-side rendering logic in MMORPG Tycoon 2.  Simpler codebases lead to faster development!  But simplifying codebases takes a lot of time.  Especially when you’re doing it in your spare time.

We’re now up and running on the new server.  I think that everything has been moved across successfully, but please let me know if you spot anything that’s not working the way that it used to be working.  (Yes, the ‘forum’ link is temporarily disabled.  Let me know if you notice any other broken links, though!)