My Rocinante Sails at Night on Her Final Flight

Today was the last day of my contract with the XNA team (non-employees can only work for one year). I had a blast working with them and hopefully I will do so again. Leaving is pretty bittersweet - I want to keep working there, but now I also get to work on the XNA book full-time and get that out the door. My current plan is to spend a couple months doing that and maybe spend some time on game development once I put the book to bed. (regarding the title of this post: I've been listening to a lot of Rush lately in anticipation of their next album.) In other news, there was an XNA user group for Microsoft employees this week. It was a lot of fun meeting folks developing XNA games and there are a couple things I want to share. Respect Da Normals One of the guys had a problem - he had game terrain made up of tiles using 3D objects (as opposed to quads) and each row of tiles was unevenly colored. One side of each tile was completely black, making the whole terrain look like a farm with furrowed rows. Clearly a lighting problem. We suspected that the vertex normals weren't right (he was using vertex lighting) but they were fine in 3DS Max. In 3DS Max, each vertex had 3 normals pointing in the proper directions. But then we re-imported the FBX file, and BAM - the vertex normal was the average of the three distinct normals we had been seeing in 3DS Max. This meant that the vertex normals were pointing away from the light on the far side, so the light color was black, and getting averaged with the vertices on the other side, which were lit normally. We started playing around with 3DS Max, and sure enough on the Export dialog there was a checkbox that said something that can roughly be translated as "Respect Da Normals". Of course it's unchecked by default. But paying attention to your normals is good advice for any time. Avoid Solutions that are Too General We were discussing how you might build a texture manager to load textures on demand and unload them when they're not being used. I suggested a simple COM-like approach - refcount the texture on Load(), and expect a Release() call for the texture to decrement the refcount. "What happens if they don't call Release?" "@#$% 'em", I said. "@#$% 'em?" "@#$% 'em," I repeated. My reasoning is that, especially in game programming, there is such a thing as building a too-general solution. If a programmer uses one of your objects for a game and they don't follow the contract you specify, let 'em suffer. They'll pay the price by keeping the texture in memory if they fail to release it. Like the rule against premature optimization ("don't do it"), you should consider a similar rule against building solutions to problems that most game designers should know better than to cause.