Hey guys! Keeping it brief, I spent today taking all the assets that George produced for our gate mockup, and turning them into a functioning environment. As a side feature, courtesy of Metadept, we now also have the ability to make players spawn in specific locations on a dungeon piece. This is handy for quicker testing of dungeons (no need to locate them anymore) and will be ideal for our mission content that’ll come later down the line.

Good night!

Hey folks! I’m afraid I don’t have anything terribly exciting to report today as I’ve continued chipping away at the same task I have been for the past week, which is making more cool stuff to find underground.

I must confess, it’s been a bit tricky working on underground content of this nature. These things can’t be terribly big and it’s not really possible to know what kind of terrain to expect around a given piece without manually painting it yourself, and doing so can cause a couple of distinct problems.

First, it can drastically decrease the ability for any given microdungeon to appear, as it tends to result in increasingly larger pieces. The smaller a microdungeon is, the higher its success rate of it spawning. The other problem is chiefly that manually carving out the surrounding terrain to form the kind of shapes you want can be really time-consuming, and that clashes with the objective of pumping the underground full of as many of these things as possible. As a result, I tend to keep the shaping of terrain around these things fairly minimal.

For now, I’ll be continuing to work as I have until I’m needed on the progression stuff again. Allow me to leave you with a sample of one of the many Avian microdungeons I designed today.

Most microdungeons won’t be as easy to spot as this one. ;)
Until next time guys!

As you’ve heard from metadept and omni, I’ve been working on a *complete* rewrite of the tile rendering engine.  The old code was a nightmare of huge repeated hard coded blocks of logic, had long standing bugs, was *dog* slow, and was actually 3 systems running in parallel (one for regular materials, one for platforms, and one for neighbor based tiles like pipes).  I’m nearly finished now with a brand new system, replacing the old complicated set of systems with one simple(r) rule based system that is about a 10th the size in terms of lines of code.

Even though the new renderer is running the new tile neighbor rules system for every single tile every single frame, the fullscreen cpu usage of starbound has actually gone *down* by about 30%*.  The next step is to add caching of chunks into the system so that the geometry for each chunk is re-used for future frames if the chunk has not changed (the system was designed from the start with this in mind).  This should further reduce the cpu usage *dramatically*.

This isn’t committed quite yet, as there are some small missing graphical features which would freak the artists out like not color shifting the materials properly and messed up preview tiles.  Once those small issues are fixed, and caching is added, it can be committed to master.  I’m hoping I can finish this up by early tomorrow, and I should have some better performance numbers then.

(*) The 30% figure is partially due to the new tile rendering system and partially due to some other related changes which also improve perf, it’s hard to tease out which is which.