Friday 30 May 2014

Potpourri Of Performance Perks

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.

7 comments:

  1. (Until next week, have a good weekend and try to get outside ) You to Lee,have a good weekend.

    ReplyDelete
  2. Simply amazing work you guy's are doing, I was wondering about F9 fly through myself and you just answered it:)
    All the same, game design isn't about throwing the kitchen sink in there and expecting to get decent FPS, it may be a stress test but isn't really practical in a design sense. Some of the work has to be planned out by the user to ensure optimum performance.

    ReplyDelete
  3. I was wondering if you will get the Occlusion system working. For me it does not return any occlusion at all at 100%? I figure if that system was working it would speed things up on level with lots of (e). Also, how do you find out the total and individual (e) index numbers that are on the grid.
    Thanks for your hard work

    ReplyDelete
  4. For me the entity shader is the most draining on my laptop,so a fix there would be greatly appreciated.Great work Lee:)

    ReplyDelete
  5. @micheal check the forum s under scripting examples by smallg he has come up with a lua occlusion system that works well for really large levels, also it was never an eight second wait that was the issue it was when I could make a toasted sandwich and it still hadn't got past ai obstacles :)

    ReplyDelete
    Replies
    1. Awesome!! I see someone quadrupled their frame-rate with it! Those kind of results are typical with this type of occlusion.

      http://fpscrforum.thegamecreators.com/?m=forum_view&t=207801&b=2&msg=2488592#m2488592

      Next step is to find a way to identify specific entities within the script. But in an earlier script in the same thread smallg had an idea of putting entities into a group, which could be identified. So incorporating this might be a great way to target specifically defined/shaped areas where such occlusion would be highly valuable.

      Delete
  6. Amazing occlusion script indeed!

    ReplyDelete