Sunday, 9 March 2014

Weekend Research


Did a little research over the weekend on the subject of lighting models in relation to performance. There is an argument for implementing something like a cluster deferred lighting renderer which has the potential to reduce the 'lighting/shadow cost' which was the route cause of the present performance issues. Alas such an implementation (done correctly) will require an upgrade to DirectX11 and a new deferred rendering pipeline which combined would take a few months of dedicated coding. That is, nothing else would get done while this work happened, and the kicker would be that some users will not even notice the difference, aside from some frame rate changes and the benefit of adding thousands of lights without a performance hit.  It is a thankless task that has more long-term benefits than short term goodies.

I expect everyone wants performance yesterday so will not be willing to sanction a six month sabbatical while Lee buggers off to re-write the entire graphics engine. To that end, the smart course is to finish the optimization work on the DX9 engine and get it as fast as it needs to go, so that when we do upgrade to DX11, we still have a very good fall-back for those users still using Windows XP and Vista (DX11 won't work on those OS platforms I think). Moreover, DX11.2 only works with Windows 8.2. See the pattern ;)

Anyhoo, the reason for my quick weekend blog is to write down a small idea I had about the shadow system I am working on. Right now the fast entity shader (LOWEST) does not use the dynamic terrain shadow texture due to the relatively low resolution texture and the lack of any meta data in the shadow texture to work out whether to shade entities at higher elevations (i.e. the roof gets a shadow when it should not).

My simple (and fastish) idea is to feed in the texture holding the height map data of the terrain, which will give each XZ coordinate a world space height position. I then write how 'deep' the shadow pixel in the dynamic terrain shadow texture is instead of just black/white. From these two pieces of information, I can work out whether a single world space position of the entity is in or out of the shadow being cast.  I would have to increase the texture size of the dynamic shadow texture to get a better finish, and there is a concern that the extra per-pixel calculations and texture read might create some drag factor in terms of performance, but the theory is sound in my mind. It's not a lot of work and it would mean entities get 'almost' true shadowing, just as terrain and grass currently receives.

I have all day Monday to work on this, plus the other ideas I have, and the big job of getting it all on an Ultrabook as my meeting is over 100 miles away from my main machine. It's a good test however as GDC is even further and this trial run will be very revealing.


And now, I will forget all that stuff and see if I can boot up Thief and continue my pilfering in the dark and rain soaked streets of what looks like London. It's possible they put Big Ben in there for the 'pending' UK tax breaks. It will be interesting to see UK developed titles in the next few years coming out with all manner of Britishness crow-barred in. The next time you play a fast paced zombie-horror blood-splat gore-fest shooter, and have to consume 'cream teas and buttered scones while affecting a cockney accent' to restore your health, you can blame the politicians of Europe! Interesting times!!


  1. Interesting ideas there, Lee. I suspect the extra pixel shader calculations and the tex read would create only a minimal decrease in performance.... just my guess. I don't know, maybe it would be worth creating an "even lower than lowest" setting with the inaccurate shadows.

    What's this about UK tax things and Britishness invading games? I don't watch broadcast TV much (looooots of DVDs) so I don't see the news.

    1. I want to know this too. I hadn't heard anything about this.

    2. I found this.

    3. Ah, that explains it somewhat. Thanks for finding that :)

  2. Lee! In the version I currently have (beta 1.004; I haven't downloaded the latest version), vsync is turned on. I can tell by flicking the screen back and forth and I see no tearing....that and the fact that the mouse is laggy.

    I refuse to accept this until you tell me why you've ignored me before about this. I'll download the latest version tonight in off-peak internet, but if I find it's still turned on, I will hound you until you give us the option.


    If, however, you have given us the option in beta 1.005, then I apologise for ranting. Again, I'll download beta5 and try it tonight.

    1. In the latest build VSYNC is turned off by default. You can have it back by using VSYNC=1 in the SETUP.INI. You will find capping to the refresh rate is a good idea when your overall frame rate is around the 60 fps mark as it makes your games super smooth. You can however remind me after the performance improvements have been made to ensure that when the monitor refresh is higher, let's say 100 Hertz, that I subdivide my physics steps to match. Currently they are sliced as denominations of 120 fps so any refresh rate that does not fit this slice will show some choppy-ness.

    2. Ah in that case I apologise. I should have just waited and downloaded the latest version before complaining.

      However, if you need framerate limited to 60fps you should use a different method to vsync. Trust me, it's one of the very first things gamers turn OFF if the game doesn't run well. It has to run extremely well before you can turn on vsync as it can easily halve the framerate. It's not a simple cap, it slows the entire program and causes mouselag. All competition gamers turn it off because of the lag it causes, even on the biggest gaming rigs.

      Vsync should ALWAYS be an option, and a high-end option at that.

      And I just tried a few things and I'm not convinced vsync is being turned off when I set vsync=0. I still see no tearing after restarting the program and the mouselook is just as laggy. The get-to-the-river level runs exactly the same with the vsync setting at 1 or 0.

      Finally, I'm sure there must be a better way of handling the physics that doesn't make everything slow down when the framerate goes slow. I've never seen any game do what Reloaded does, where lowered framerate equals lowered movement speed and animation.

      Again, sorry for my ranting, but as with the squished view before you discovered you were setting the horizontal FOV with vertical FOV (or whatever it was), I kinda feel like you don't believe me.

      Can't wait for the next version with all those performance improvements you've got waiting for us :D

  3. It's great to see you making progress like this Lee, you actually sound like your enjoying the challense.

  4. Dx11 would have been a nice little add on, Dx10 is a complete waste of time, nothing wrong with DX9, it's still very visually pleasing.

    I DEMAND the entity light mapping/collision and shadows working in the next beta :p I have to warn you I have read Misery.....:D