Development log
by Ivan Kravarščan
The colony panel is slowly getting more populated. Description and breakdown dialogs are really exhausting to port for some reason. I’ve optimized my flow for copy paste, both between versions and between features and it still feels like it takes an hour per dialog…
By now all components above colony management are covered: population, factory, and troop info, and industry, research, and supply outputs. I’ll do output icons later. I’m looking forward to colony management components, they should be less labor intensive (no elaborate calculation breakdown) while providing actual means for playing the game.
You know what’s cool? Postprocessing effects! Especially when you can sneak them in as a normal rendering step. I’ve been delaying this for a while, hoping there is a “single pass” shader trick that would be good enough and I couldn’t find it. But I’m getting ahead of myself.
Why do I need blur at all? Overlapping panels have been visually bugging me since the very beginning. There is not much going on on the start screen (for now) but the “select mode” dialog still looks slightly off. As a portion of the star image slides below the dialog, the text is not as legible above it as it should be. I’ve played with various transparency values and none of them clicked with me, especially not the fully opaque black. That looks like the void ate the middle of the screen. Ideally the opaque background would be the answer but it would have to have a texture, some sort of noise.
I’m not good at textures so blur was the second best choice. It softens the background while still leaving it visually present. That softening effect is even more effective on the galaxy map that is full of sharp, one pixel wide lines. So I gave it a chance and dug in to figure out how to do the blur properly. The reason why blur is a postprocessing effect is because each blurred pixel requires the color information of unblurred pixels both left and right, and above and below. So you need to have the complete unblurred scene in order to blur it. Implementing that requires juggling drawing surfaces, the unblurred scene needs to be drawn on the “off screen” surface and then converted to an input image.
LibGDX is quite convenient for managing those off screen surfaces (frame buffers, and their respective color textures) and I’ve found a way for redirecting where UI is being drawn without nuking and rebuilding the framework’s rendering logic. In fact, the framework proved to be so convenient that the postprocessing red tape ended up looking like an ordinary UI component. Um, it’s hard to describe without walking through the code but believe me, I’m still astonished with how little intervention it took.
tags: