DT: Cubemitter Optimizations

Hey everyone, Team Stonehearth is  just now fixing the very last of the bugs on Alpha 20, gearing up for Alpha 21, which will focus even more on hearthlings, their personalities, quirks and foibles.  Today for Desktop Tuesday, and before we close the book on Alpha 20, let’s take a closer look at the performance upgrades that engineer Justin has added to the Cubemitter! Short version: games with a lot of particle effects should stutter a lot less now. 

The Cubemitter, Memory, and Me

Recap from the video:

  • For a long time now, we’ve heard from you that the game can start to stutter when night falls, and all the lights and firepits–if you’re lucky enough to have multiple–turn on.
  • We’ve also seen slowdowns in games that have stockpiles full of talismans or worse, rotting food. 
  • All of these performance issues stem from the fact that our particle vfx system, the cubemitter, was written in house by Chris, and while it is fantastically flexible, can be authored and updated in realtime, and easily produces everything from fire to water to magic effects, it can consume a lot of memory very inefficiently.
  • When Justin started on the team during the development of Alpha 20, Chris asked him to take a look at what could be done to make the cubemitter more efficient and cause the game to stutter less. He figured it would be a great way for Justin to begin to get into the rendering and engine code, as well as knock off a performance optimization we’ve been meaning to make for years.
  • One of the first things that Justin looked at, was the fact that when the cubemitter is running, it’s constantly asking the computer to give it a bit more memory so that it can create more cubes to show on screen.
  • Memory allocation is one of the most expensive operations you can ask of the operating systems, so if it’s happening a lot, across hundreds of cubemitters, you’ll see a continuous stutter as the computer continuously parcels more and more memory out to the game.
  • Another problem that frequent memory allocation creates is that of memory fragmentation.
  • When Stonehearth starts, the operating system tries to grant the game one large, continuous piece of memory to work with. Every time we create an object in the game, we use up a little bit of that data.
  • To prevent the game from running out of memory, we have to delete chunks of memory we’re no longer using, so other objects can be written up there.
  • Because the amount of memory requested for each cube is so small, the memory space of the game becomes divided into thousands of tiny little slices. When a cubemitter is released, like when the firepit goes out, we have to delete all these thousands of slices one by one, which takes a long time.
  • To fix both of these problems, Justin now pre-calculates how many cubes a cubemitter will need and allocates all of them up front. This means that the game will stutter less, because we won’t constantly be asking the computer for more memory while we’re running the effect, and that the game will be much more efficient about cleaning itself up afterwards, because all the memory will get cleaned up in one chunk, instead of thousands of little chunks.
  • In order to test the efficiency of his changes, Justin created a test world which has sample cubemitters from every part of the game–hearthling and goblin firepits, the coal effects from the blacksmith’s forge and the Rayya’s Children tier 2 braziers, fire from the fire arrows, water from the fountains, and dust clouds from the poof effects.
  • He then made his performance and memory allocation changes, and then ran the game through a performance and memory profiler called vTune, to get a sense of how performance and memory allocations worked in Alpha 19, before his changes, and then in Alpha 20, after his changes.
  • Before Justin changes, we spent quite a lot of time accessing memory, which is a function that’s very slow. After his changes, our memory allocation time has gone down by a factor of ten, and towns full of lights and fires should perform a lot more efficiently.


Other Announcements

This Thursday’s stream will feature Matt Malley, who has given us a ton of the VFX you see above, as well as all the adorable animations from A20.

Today, I am also incredibly excited to announce that Carl Quinn is joining Team Stonehearth as a very senior engineer. Carl has been working at Riot for some time as an architect of our various backend services. Previous to Riot, he’s worked at Borland on Borland C++ at Sun on Java Studio Creator, at Google on the Blaze build system, and at Netflix as the Engtools Team manager. Quite frankly, we are gobsmacked by how lucky we are that he’s found our little game worthy of his professional skills. In his very first week on the team, Carl has bravely gotten waist deep into the swamp of our lamentably disorganized hotkey system, which should give him a good tour of the skeletons in our engine at the C++, Lua, and Javascript layers. Please welcome Carl to our community on via @carl_quinn