For some time now I've suffered with abominable build times on my optimized builds. A full rebuild of just the client in Debug takes 160,825ms but in Release it takes 371,462ms. So for less code, that's a whopping 231% increase in build time just for optimization!
I build three different configurations of my game. Debug is a build with all debugging features enabled, ASSERT's on and debug trace output. Release has full optimization, no ASSERT's or trace output. I also have an Abort built which is fully optimized with ASSERT's and no trace output. I use the Abort build often, but the 6 minute build times even for a one-line change make it super-inconvenient to iterate.
I've spent quite a bit of time the last couple weeks piecing bits of different articles together to figure out how to implement normal mapping in the Lair Engine. The problem I encountered is that there is a huge variation in the methods and terminology used for normal mapping. This makes it a very confusing topic for non-math-lovers like myself. So here I'm going to explain the three common techniques for normal mapping for the mathematically uninclined.
Thursday morning it occurred to me that today would mark the 4 year anniversary of the start of my work on The Imperial Realm :: Miranda
which made me think, "it's about time I put up some real, unretouched in-game screenshots."
[Waiting out the Sandstorm]
[Immovable Object, Meet The Irresistible Force]
I love the sand storm effect! Sometimes I park the camera under a ridge and watch the sand blow over my head. Getting all those particles interacting with the terrain at a decent frame rate was tough.
These screenshots show The Wasteland, one of several biomes in the game. It is hot, white sand, and rock and nothing lives there except some curious flowers. Anything you can see in the screenshots you can go to with no immersion-breaking load screens.
You may have noticed the second shot borrows a note from Oblivion
. I loved the shots of Jack motorcycling between buried ships in a post-apocalyptic wasteland. If the final game reminds you a bit of Iceland, Oblivion
Here is a good example of why multithreading is hard.
I can't remember the last time I had to spend any time finding a memory stomp. This was not always the case -- I have spent many an hour with data breakpoints
. Man was I happy when those finally started working on the Wii. Today I thought I'd share a couple little things I use to eliminate overflows in my code.
I always hated working on games that didn't have a working debug build. On some the framerate was too low. Some didn't even build. There was always one real reason for it: somebody in charge didn't think it was worth having a running debug build. But the cost of a broken debug build is a huge increase in bugfixing time. Debugging a non-debug build results in misleading values in your debugging windows, bad callstacks, and heavy reliance on static analysis of trace output to figure out what has gone wrong. In short: it has a huge cost in developer time.
I've been stuck on this for a week, so I'm putting it out as a Friday puzzle challenge. Can you tell me what I'm doing wrong?
I added the normal mapping code from Followup: Normal Mapping Without Precomputed Tangents
. I have other normal mapping code which uses the usual method of passing the tangent vector with the vertex data and that works great. There's no vertex shader code on The Tenth Planet, so I had to figure that out myself.
The problem I have is that if I use the normal from perturb_normal, the lighting rotates with the model so it is always the same side of the model that is lit (beautifully) no matter how the model is oriented relative to the light source. If I light the model with the interpolated vertex normal I get smooth n dot l lighting which works as expected.
In my quest to increase draw distance, I needed to find a way to reduce the number of triangles in my terrain block meshes from 7938 to something much smaller but that still retained the overall shape of the original block. I found lots of algorithms for decimating (reducing the number of triangles in) meshes but nothing specific to terrain meshes.
I read this post on AltDevBlogADay
which made me decide to finally post this:
I was approached by a fresh-faced rep from Hansoft at Game Developers Conference a couple years ago. She asked me if I used project management tools, and after replying that I used their software, she was really excited and asked me what I thought of it. I told her I had never seen a product so thoroughly designed to make people feel bad about their work. She stared at me blank faced, then handed over one of every tchotchke they had in their booth.
The toys didn't make me feel any better about Hansoft. Do you have a happy team? Hansoft may well drive it into the ground.
40 sounds like a lot, but its actually 20 for two factions (I'm still working out a strategy for the other two factions units) so if you consider there are 6 manufacturing buildings, silos, walls, power plants, and base defenses, it isn't actually ...
Interesting stuff. I loved Red Alert back in the day (to be honest often more for the base building). I did feel that there was always another layer of gameplay that occasionally peaked through inevitable the tank rushes/big blob of units. There was ...
I'm pretty sure it's the one.
I have been visiting your website and watching the development process as closely as you will allow here since the beginning. As someone who has many thousands of hours logged in MMORTS games, I can see the potential with this one. It this "the ...
Good luck, can't wait to try it myself