A mixed bag today, with both key fixes and more performance revelations. Instead of a funny video today, I will blast through the updates we did today. It is Friday after all, and I have tools to pack for my return to the world of interior decorating. Until next week, here is the task list of done items:
In addition to the new reflection slider modes which switch the resolution control to the SETUP.INI, replacing it with controlling the 'size' of entities that get reflected (88 is a good value in the next update), we have added the extra mode which when the slider is at zero, the water plane is entirely removed from the rendering, providing a few more precious FPS points. The water generation system which calculates the alpha channel when water is near the shore now skips if the water was not changed since the previous test session. Increased the speed of the Desert terrain choice by converting the textures to use DXT5 compression. Ravey fixed a huge bug which means characters can no longer 'walk through walls', which you will agree removes a significant advantage from the enemy. Pressing F9 in Standalone Game has now been disabled so you cannot play someones game and cheat by carving out your own path through the level. Gun sounds tweaked for more authentic audio. Adjusted the two-compounds level with better defaults which means you will get a faster level by default, and restored the bloom level so you get a nicer looking scene by default also.
I ran some tests to see if batching would improve performance, and although there are signs that this might work for some older cards and chips, on my machine (9600 GT) my three tests to batch 4500 polygon buildings, 500 poly rocks and 32 poly crates all resulted in zero performance gain. Seems my card was happy with 5 draw calls of 100 polys or 1 draw call of 500 poly?! We have another theory which would be to build the batch in a dynamic vertex buffer on the fly (after frustum culling) but given the slight performance savings shown in early tests (when you factor in additional VB locks per texture/shader) I decided to look elsewhere for a performance boost.
And I found it. Seems that my terrain shader is still very heavy on the fragment shader usage, and when I switched it for a single return float4(1,1,1,1) I went from 170 fps to over 550 fps. I then postulated an idea where I could split the shader usage between the current one at close range and an entirely different one when in the distance. This should yield me upwards of 5-10 fps gain under the 60 fps mark, which would be huge. The same is likely true of the entities as well, so this will be my task on Tuesday. Monday is an all day strategy meeting so no coding from me for the most part.
We also eliminated the huge delay when calculating AI obstacles which means no more EIGHT second delay each time you click Test Level. Fixed a crash caused when painting grass at the extreme limit of the level. When the player re-spawns the player orientation is restored to the correct angle and the gun will be reset if you were in mid-fire when you died.
We're all still on a mission to gain more and more performance before we release another update, and so far we have gone from mid-20's to low-50's so we're only a few hops to the golden 60 fps score we're all after. More speed to be gained from grass, terrain and entity rendering, faster Test Level preparation as we skip redundant generations and closing the book on some silly bugs still in there and we'll have a pretty strong release to make all your competition entries that little bit faster. I also have a handful of VERY large levels from community members, and will be ensuring the engine can load and handle them before handing back the levels.
Until next week, have a good weekend and try to get outside from time to time. It was nice and sunny today so my hope is the trend will continue over the next two days so I can catch some rays.