Asylum – Dev Diary 24 – Faster Damn It!

This week, as seems to be the norm at the moment, was a disrupted one; but there is a May bank holiday weekend coming up so I should be able to dedicate more time for development next weekend.

This weekend I’ve been trying out a different lighting engine, with limited success. I managed to get some of the lighting replicated using the alternative engine but it was proving a little too time consuming so for the moment I’ve scrapped that idea and returned to my current lighting engine. Shame as the new one was purely shader based and increased the frame per second quite a bit.

And so, I decided to go through as many scripts as possible and see if there was any aspect of them I could optimise to bring the FPS up a bit.

The lighting is obviously the main performance hit, without the shadowing the game storms along at more than 1000fps in places! But it looks naff so that’s never going to happen. There are 2 types of light in the game; static and dynamic. Dynamic lights are important for when objects move within their influence; the shadows move and give the effect I’m looking for. Static lights, obviously do not update at all. Generally speaking most lights in the game are dynamic, but I can switch the lights between the two states. So, I’ve altered the lights so that when the player is no where near them and so can’t affect the shadows the light is switched to the fast static light. When the player gets within range the light is switch back to being dynamic.

As I’ve been developing the game I’ve added quite a few debug messages so that I can see what is actually happening behind the scenes while I test parts out. I’m not sure what the impact of these are on the game (when compiled it would be zero) so I’ve cut out some of the messages that I no longer need.

The other aspect that needed a bit of optimising is the interaction elements. For these I have to cast a ray to see if the player is within a certain radius of the object and also that the object isn’t behind something else like a wall. Again this may be costly for performance as it was checking all the time. So, instead of using a ray caster at all times I’ve put in an initial distance test. If the player is outside of this range the ray cast doesn’t happen.

All of these optimisations have increased the fps in the slowest are of the level by 20fps, so I’m pretty pleased with that outcome. I’m sure there’s a few more tweaks I can make as I continue development.