The BitBull Blog

For the past week or so I’ve been working on sorting out a few visual things that have been bugging me. I’ve also been busy with contract work and work on a rental property, and it’s been unbearably hot and the window is my office has jammed shut – this is why thing seem to have been moving slowly. Actually the coding has been going pretty fast when I’ve found time to do it and I feel like I’ve been zipping along compared to working on those damned bosses!

Anyway, here’s what I’ve been up to…

1. Scrolling Improvements
One things that’s been really annoying me has been a slight ‘judder’ to the scrolling of certain items. The more observant of you may have noticed this in some of the previous GIFs. It was obvious on some of the pickups and sometimes in the way the ground moved in relation to the buildings. There were a number of reasons for this…

Firstly, I had built the ground as a layer of parallax rather than an object in the world itself. This was dumb. I’ve transferred the ground tiles to actually be part of the world and move with the main game camera.

Secondly – rounding errors. This had me scratching my head for a while but I eventually figured out that the way the game scaled was the cause of the problem. I scale up all the game graphics based on the size of the screen and calculate their positions at full resolution (for smooth movement). As I position sprites from their centre point this meant that, if the scale size was an odd number AND the size of the sprite was an odd number you end up with a sprite of odd dimensions which is never going to be positioned consistently with a sprite of even dimensions (as positions always have to be rounded to an integer for display onscreen). The solution to this was to ensure that all sprites that can be positioned stationary on the ground have even dimensions.

Thirdly – rounding errors part 2! When sprites came to rest they would often land at some fractional x position which would lead to a similar problem as I’ve described above. The solution to this was to ensure that sprite positions are rounded to integers when they come to rest. This has no visual effect (as they’re rounded to integers for drawing anyway) but it makes for solid-looking scrolling.

2. Impact Shader
What seems like an eternity ago now I added a ‘judder’ effect along with camera shake to give a more visceral quality to explosions and collisions. This effect was causing performance issues on some machines (as it required the entire screen to be re-rendered twice with a custom shader) plus I was never entirely happy with it. See the original effect here.

Recently I made changes to the way buildings are rendered so that they are pre-rendered to individual offscreen images rather than being rendered ‘on the fly’ as tiles. This enabled me to create a ‘judder’ effect by rendering the individual buildings with a custom shader rather than the entire screen. It also meant I could change the offset of the effect subtly per building based on the epicentre of the explosion/collision. It looks better and should perform considerably better too.

3. Smoke
Again, what seems like an eternity ago, I added a smoke effect which I always felt looked a little too ‘high res’ for the rest of the art style and was also causing a few performance issues on some machines. You can see the effect here (I usually turn this off for recording GIFs as it overloads the GIF compression).

I’ve redone this smoke effect. Each smoke cloud is now rendered in one pass (rather than a separate pass for each ‘particle’ in the previous method). The particle positions are calculated on the CPU (trivial) and passed to the shader each frame.

This enables me to give a ‘posterizing’ effect, ie reducing the amount of alpha levels where the smoke particles overlap. I can also render at a size consistent with the rest of the art and scale up to draw on screen, plus I’ve added a pseudo ‘dither’ effect for more lo-fi goodness. I’ve also got a lot more flexibility now for adding smoke clouds of different sizes.

I liked the previous effect but I think this one is much more in keeping with the overall art style.

4. Burst Geometry
Wasn’t intending to do this but, in the process of rationalising all my shader FX into my ‘mother of all geometry shaders’ I realised I hadn’t covered the ‘burst’ effect that I use for the muzzle flash on the gatling gun. So I felt obliged to sort this out, then I realised there were problems with the algorithm so I had to change the algorithm, then I had to add proper fades, cropping and looping to it. I also sorted out memory management for the geometry shader sprites (as I’m using them a lot now) so that they’re pooled as opposed to being created and destroyed each time.

Dev Time: 5 days (bit of a guess, I kind of lost track with a lot going on)
Total Dev Time: approx 214.5 days

previous | next