Today was general cleanup, and setting goals for the rest of the month. Also fixed a couple of memory leaks that I’d been putting off looking at for a couple of days. The benefit of having memory leak detection and tracking built directly into your game engine is that those leaks are easy to find. The downside is that the game’s incessant whinging about unfreed blocks of memory can be quite distracting when you’d rather be working of more exciting things. (Which is, of course, why it’s important to include that incessant whinging)
Oh, and I also added basic renderable buildings in the cities, just to give me some better visualisation than the flat outlines. And yes, this city is sitting in the middle of an ocean (mostly because I didn’t want to have to deal with laying out a city on the side of a mountain yet). It’s still much, much too big; those simple block buildings are absolutely massive; most of them are anywhere from three to five stories tall; much bigger than they appear to be in this screenshot. You don’t realise just how huge they are until you’re actually standing (technically swimming, since it’s the ocean) next to them. It’ll be easier to sell their scale once I start generating more detail for the buildings than simply extruding the shape of the plots of land that they’re sitting on.
In the screenshot, my cursor is helpfully pointing out a bug in my code which shrinks building plots for the purpose of creating streets and alleys between the buildings; the corners of this triangular building have actually travelled past each other. Oops! I’ll have to cater for that, eventually.
Today I also handled a minor issue in my procedural generation stuff, which was the result of different bits of code using different assumptions about how to arrange data for one of my proc geo classes. After much soul-searching, I finally picked the simpler-but-less-powerful of the two approaches, and modified everything to work that way. I’ll probably regret that eventually, but for now, at least things are consistant.
I also did some debugging of the vsMeshMaker class (which I wrote for GiaW #6, and is available in the public VectorStorm library source code), and how it merges vertices together when baking a set of triangles into a renderable model. I’ve now absolutely proven that the weird sharp lighting changes in some models (most notably the “starting area” model) are definitely being caused by the vertex merging code in vsMeshMaker (the other candidate was the minor issue in the procedural generation stuff I mentioned above, but that turned out not to be the cause of this particular bug). I don’t really have the brain space to fix the lighting weirdness right now, but at least I’ve proven exactly which lines of which file the problem is in. I’ll work out the fix for it later, when it’s more critically important.
Finally, I’ve been working out the fine details of general gameplay for a full prototype that I’m going to be putting together over the next month. I’ve almost gotten everything worked out; I’m looking forward to starting on the required features tomorrow!
