A Day in the Life of a Programmer

The programming team codenamed our current milestone El Dorado after the mythical city that doesn’t really exist. Most of the stuff that we have been doing towards El Dorado… well, it isn’t ready yet. Also, a lot of it is systems which are transparent to the user (networking, refactoring, serialization, etc.) It’s all important, but it’s not glamorous. We should, however, have a few interesting things to show next week. We (well, mainly Micah) wrote up some of the work that we did on our threading and messaging system, and submitted it to an academic conference; I am pleased to report that HotPAR ’13 (the Usenix Hot Topics in Parallelism conference) decided to accept our paper, which will be presented at some point in June. I should figure out when that is…

So instead of the big Technical Status Update, which we’ll probably do next week, let’s look at a very small slice of life that makes a big difference. A lot of people ask me what it’s like doing game development, as a day-to-day process as opposed to the big picture; this is a good example of what it’s actually like on a given day, what graphics programmer thought processes are like, and so on and so forth. Also, I’ve included the picture of a tortoise next to a pile of ammunition that David refused to last week.

One of the things that I did recently was to fix the shadow code up a bit. Shadow code, you may recall, was one of the first things I did for CE, simply so I could figure out where people’s feet were. We rendered a shadow map from a fixed view point, and so you got chunkies like this:

Tortoise Ammo 1

Note that this picture looks fine – until you zoom up close, at which point you’ll see the problem. Shadow artifacts like that occur when the shadow map in question – which is basically a texture – stretches so that more than one pixel on the screen are covered by the same texel of lighting information. The end result was that – in addition to the chunky artifacts you see on the rim of the shadow, as you moved around the map close up, shadows would shimmer like a heatwave as you moved about the map. The first type of artifact can be described (loosely) as spatial aliasing; the second type of artifact is what I would call temporal aliasing (that only appears when you move.)

The general solution is to implement what are called Cascaded Shadow Maps, where you have multiple shadow maps in a big stack; areas of the screen that are closer to you are rendered in one shadow map, areas further away are rendered in another one, etc. Well, that’s no use for CE; everything on screen is about the same distance from you at all times.

I didn’t want to just change the zoom level of the shadow map as you zoomed in with the mouse wheel. In particular, I worried that it would be a shimmering mess of jaggies that would look awful, just awful, when you zoomed in and out; in other words, we’d be replacing one sort of aliasing with another sort of aliasing. I considered more and more dramatic solutions, including having enormous shadow maps that we updated sporadically and doing all kinds of other wacky stuff, until finally I wondered if the temporal aliasing caused by just zooming in and out on the shadow map would really be all that bad.

In fact, it was totally fine. Shadows now look like this:

Tortoise Ammo 2

with no noticeable change in performance, and look just fine zoomed out as well. If I had to name a reason why this works, I’d say that any possible changes in which sample we pull from the texture as we zoom in and out are masked by the small 9-tap percentage closer filtering we use on our shadow maps to give them nice, soft edges.

Moral of the story: good programmers challenge their assumptions constantly.

Posted in Clockwork Empires, Gaslamp, Programming | Tagged , , , , , , , , , , , , , , , ,

18 Responses to “A Day in the Life of a Programmer”

  1. Df458 says:

    As a college programmer who hopes to end up doing either graphics or engine programming for a living in a few years, I find these programming posts to be quite enjoyable to read.

    { reply }
  2. icepick37 says:

    I am terrified of the day when I have to do graphics programming, haha. I have so little clue what is going on there. Sigh… Not that I couldn’t figure it out. I just haven’t had any experience with it.

    Good work, by the way. The shadows look really nice!

    { reply }
  3. Kazeto says:

    “does anybody care about this stuff” – yes, we do, Sir Nicholas.

    In fact, for many people reading these posts it gives a kind of a sense of comfort, to be able to see how the game is being created and shaped instead of only seeing promises about “how will the game-play look”.

    But I’m digressing, am I not?

    { reply }
    • tentacled-godqueen says:

      I am also interested, yeah; there are programmers reading this blog.

      (Although this sort of graphics code isn’t a thing I’ve done, unlike the last post about pathing and stuff; but it’s still interesting)

      { reply }
    • Bluerps says:

      Just wanted to add my voice to the people who care.

      Also, congratulations for getting your paper accepted!

      { reply }
  4. Xyvik says:

    “startling new evidence of the tortoise survivalist movement” eh?

    I give you evidence of other creatures needing survival! http://www.homestarrunner.com/pistols4pandas.html

    Anyway, I love the icon and the pictures. Shadows are looking good!

    { reply }
  5. Bropocalypse says:

    Tortoise survivalists, huh. Makes sense, what with the camo colors and having a helmet-shaped body.

    { reply }
  6. Darren Grey says:

    Good to see you have this nailed. So many AAA games have awful looking shadows (I’m looking at you, Skyrim) so it’s good to know the plucky indie company found a good solution 🙂

    { reply }
  7. Bropocalypse says:

    You know, I have to say, those super-sharp shadows kind of bother me, actually. Light diffuses a bit more than that, doesn’t it?

    { reply }
    • Correct! You get the Graphics Star.

      Shadows should be sharper, but soft shadows – real soft shadows – mean a higher number of samples taken from the shadow map. That means more hardware taps per pixel you want to illuminate. We can up that, but there’s a speed issue. Right now it’s 9-tap PCF; I will probably add support for upping that to 16 and 25 taps for more blurring and softness.

      { reply }
  8. SangerZonvolt says:

    Is it jsut me or is that turtoise quite large?
    Also: Does that mean we can expect videos of the engine in motion any time soon?

    { reply }
  9. Jakub says:

    Thanks for another technical post, I love reading those. Takes me back to when I implemented my own shdowmaps as well, it makes such a big difference for depth perception and overall immersion / believability of the world.

    { reply }
  10. David says:

    I don’t want a rushed game but… Huuurry up!!

    { reply }
  11. Demon says:

    idk if this has been addressed so sorry if it has … BuuuuuuuuT They have possibly found El Dorado using lidar, expedition is getting put together now to go in next year.


    { reply }
  12. Annih says:

    Your paper sounds interesting, will it be available outside that conference at some point?

    { reply }
  13. Dominic says:

    Another programmer here appreciating these posts. Granted I’m not working in games, but I am doing graphics programming, so this is still interesting.

    { reply }
  14. Pingback: Dev Links: Best Defense « DIYGamer

Leave a Reply

Your email address will not be published. Required fields are marked *