Term over and optimisation!

So I haven’t posted in quite a while. Why? Because I’ve been at university, and I’ve been a LOT busier than last year. I’ve only found really small snippets of time to work on this. Now however, the first term is over, and while I still have a lot of work to do, I may just be able to find some more time to work on this. In fact, after my first term, I’ve found myself wanting to optimise the code for a lot of the engine a little. The first step is to change the image resampler. At the moment, to deal with varying screen resolutions, the game will take a texture and resample it to fit to your screen, allowing it to look clean and smooth on any sized screen. However, the algorithm I used to do this had 3 flaws:

1. It was expensive, in that it sampled every pixel in a block, and averaged them out, which is an expensive operation.
2. It was approximate, in that it would only allow scaling down an integer amount (e.g. you could resample something to half it’s original size, but not 0.6 times), and would scale down to the nearest available one and approximate the rest with nearest neighbour scaling.
3. It ran on the CPU, taking up processing time, and really not pushing it to it’s potential, where using the GPU would be far superior.

So I set about designing a new algorithm to make things faster, in order to avoid what I’m calling “Sonic ’06 Syndrome”, where the load times are so long that a significant portion of gameplay is spent just waiting for the thing to load.

I managed to fix all 3 of these problems with a new algorithm. First of all, I blur the original image. This is done with a HLSL pixel shader, which runs on the GPU. This process takes less than a second. What this achieves is a quick and cheap approximation to averaging all the pixels in a given area. Next, I simply scale the image down with nearest neighbour rescaling. Again, this is practically instant. And that’s it! The best part about this is that by giving the blur function a non-integer radius, I can get arbitrary resampling, that doesn’t just scale to the nearest available one.

Now, I don’t know if I’m going to keep this algorithm. Why? Because it’s flawed. A lot of the graphics in Decima are stored in sheets (to save on memory and time). This resampler causes some… interesting errors in the positioning of the sprites on the sheet, making the animations appear to vibrate. However, because of what I’ve done to implement this, I am confident I can keep the loading times down anyway by making use of a pixel shader, even if I have to resort to my original algorithm to do it.

That’s all from me for now. Hopefully next time I’ll have some more content to show! Sorry!