Finally, I'm back to my battle station!

Hi everyone, I'm back home so let's do this!

Last four weeks we've been busy with updating ProDnD Dungeon Generator at the office as that's the project which puts food on the table. On top of everything we've gotten a short assignment in which we assist an eager team of developers plan their development cycle. In a nutshell I've been busy with these at work and several other things I won't be listing here, however, I had the chance of working on some Wasco related material as well.

Since ProDnD & Wasco both are using the same codebase which derived from Pro-D I've imported some of the code I had cleaned while working on Wasco into the ProDnD's project folder. There's nothing like re-using refactored code you've painstakingly cleaned and tested! I'm quite happy about this to be honest. That being said, I've come across an issue with Wasco's sprite packing algorithm during this process. I decided it would be a good idea to fix this issue and improve the codebase on both sides. A two birds with one stone sort of situation if you may. Here's some explanation to what the issue is:

A screenshot of how the algoritm is currently packing the tile textures. 

Can you already tell what's wrong here?

As you can see the textures are packing in an orderly fashion, however, there's a lot of free space and the atlas texture can be way smaller. For this we need to match the atlas's texture size to the volume of sprites we have: I've been thinking of doing this by calculating the initial volume of all sprites and taking the square root of it. Let's say I have 15 x 10 by 10 sprites and 5 x 20 by 20 sprites. That would make a volume of ((15x10x10) + (5x20x20)) = 3500. And square root of 3500 is 59 which makes the best next atlas size 64 by 64. This way instead of getting the above picture where there's a lot of space being wasted, we can get a smaller size atlas texture and save on space and memory if I'm not mistaken. This method is most helpful since compression algoritms provided by Unity and most other engines support powers of two. (More on this later. It's an interesting topic.) 

After this volume calculation happens we need the following flow: A fitting algoritm needs to run through these sprites and pack them tightly all the while making sure it has the best placement option possible. If the sprites won't fit within the current texture size, since the best arrangement doesn't constitue all elements fit within it, then the algoritm will double the size to 128 by 128 and try again. This time surely fitting all and if it didn't then it can double again and again until we crash and burn our computer.

Above an example of

what I'd like to see!

If you're curious yourself as well about how a fitting algoritm should work I've found this article offering a nice solution. Here's me asking for help here at Reddit.

Until the next post!

Tunc