Work
With much performance improvements under our belt, we are at a phase now where testing takes front seat, which means making random levels until something bad happens.
This is something I ended up with while trying to trip up the engine, and thought I would take a holiday snap while I was standing there thinking.
Some great fixes today, including a physics fix, the player no longer hurts performance after a death and restart, other small improvements related to performance and final visuals. You can once again take snapshots with F10 and it seems to run very well on a variety of low end systems now. Phew!
On the IDE side, we have been working hard on getting the Store download system complete, so you can sync your purchased assets with the local library and start using Store based artwork. We have pretty much re-written the store front-end and have tried to make the client side back end as seamless as possible. Right now you just click DOWNLOAD from the FILE menu, press another button and wait. Minutes later you have all your store items on your computer :) We're putting the finishing touches to that this week.
Of all our internal alpha testers reported in so far on the latest version, only one had any remaining issues with stutter (or sluggish frames) and I am awaiting a better description or hopefully a video showing the issue. It does appear though that we have crossed over into a sweet spot and the trick now is to keep that intact while expanding the software further.
Plan for Thursday and Friday is test like it's going out of fashion. Only small tweaks now, no feature additions and plenty of paranoia as we click every button and try every combination to seek out those pesky show stoppers.
Work
Meeting day today so not much time left for serious coding. Made our shortlist for what goes into the BETA and what goes into version after that. Team working well and already discovered a 19MB leak in the GPU memory caused by real time render targets not being freed. Added code so just needs testing Wednesday to see if it worked.
I spent my 5 hours preparing the version for the build. Stutter fix went in, that was five minutes, then spent an hour on the aforementioned GPU leak fix but then spent over 3 hours on getting the characters to skip rendering into the shadow system when using cheap shadows (as they only project one pixel which is not much use). Alas after many frustrating hours, no matter what code I disable or tweak, the characters would NOT go away. Decided to change tracks and return to this one.
I am planning to do some final tests, make a new demo and release to the internal alpha testers in the hopes I have (a) not broken anything and (b) made things a little better and less stuttery for some testers. Here we go...
Work
Even though I had no power in the house until late evening, I did have the foresight to charge my mobile and my Ultrabook, plus top up my UPS to get some extra hours. Using these temporary stores of electrons, I proceeded to confirm the theory that timeGetTime() is broken. And it was!
It seems you are NOT GUARANTEED to get 1ms granularity when you call timeGetTime() and trying to get this information from the official documentation was like pulling teeth. After much ado, I discovered the granularity can be as rough as 10-15ms which means your physics would essentially freeze for 15ms before stepping to the next count. Insanity I know! Anyhoo, long story short, I replaced this with QueryPerformanceCounter() and QueryPerformanceFrequency() and presto, I got my fine grain timer working in the microsecond range (i.e. 1 millionths of a second). As soon as I added this, all stuttering I was able to produce on a low end laptop and a high end gaming rig completely disappeared.
For kicks, I had also charged the Windows Surface Tablet (so I could surf the net during my emergency power session) and put the latest version of the demo on it, dialed out some (well most) of the features and was able to get a full screen 1024x768 scene running at 33 fps, complete with rendered animation and all the back-end. Bear in mind this has a GPU score of just 112 and I managed to get a frame rate that allowed me to run around smoothly. Shocking I know, especially when you consider my previous run only got as far as 2 fps. Naturally, I would have to do a SERIOUS amount of hacking and slashing to get Reloaded to run on such a device, but it shows the feat is 'possible'. Whether this is something to community wants to see is another matter, and we have already got early grumblings from at least one community members that 'enough is enough on performance' and that we should be adding features now. I am pretty sure this is a minority view, and perhaps highlights one of the difficulties of coding in a democracy :)
Despite no power and little team comms, I achieved a substantial fix today making Monday a pretty good day. Also getting some nice reports from the internal alpha testers so all the signs are good for a great next beta. Have a meeting Tuesday morning so time for an early night (as soon as these emails are dealt with).
Work
More stuff goes into the engine today including full screen mode for standalone executables and further improving tweaks. I also managed to reproduce the stutter and then exaggerate it to see it in all it's ugliness. It turns out that the physics module is NOT to blame for this, and is more to do with the something around the SYNC command. I am currently researching the improvements DirectX made to the 'Present' command as we currently use the antiquated COPY method, and it sounds like the better system is FLIP and FLIPEX which apparently uses less memory and is much more efficient. The potential gain is zero stutter and slightly faster performance all round so wish me luck as I go back to school with DirectX :)
Work
In order to really understand what is happening out there in the real world, I have added some new debugging tools into the engine executables including the ability to switch off chunks of the engine to see which parts are causing the highest slowdowns. I have also added some extra information in there such as the graphics card name, the DirectX version and the DirectX Refresh Rate being used to control the VSYNC interval.
It's been solid tweak and test all day, and a good deal of time in the internal forum understanding exactly what is happening on the testers hardware. I have roughly half the testers up to 60 fps under certain conditions and I am working on the other half. Hardware ranges from cards that score just 450 points on the GPU up to 5000! We have yet to decide what the minimum threshold should be for GPU power. I am also starting to collect CPU power scores as well, which might play a role in my performance analysis.
I have also recommended the internal coding team download and start learning the latest NVIDIA NSIGHT debugging tool which will help us drill down into the very heart of the engine to discover those hidden gremlins. As you can see, it's all performance work today :)
Work
Another quick blog from me. Another day of developer graft as we continue ticking off little fixes between us, and the biggest decision was to postpone some Store integration work in favor of more performance tuning of the engine. We have some early results back and although half our test systems report super smooth and silky 60 fps on low-end hardware, we are getting reports of dreadful fps on what looks like mid-range systems. Very odd. Thursday will be about running multiple performance tests in parallel as we drill down to the root cause of performance drains from system to system. The good is that the core team are starting to see some nice smooth zero-stutter performances, we just need to convey those results to the other test systems now which means understanding them inside and out.
I had suspected the CPU power was the crucial factor, but this seems not to be the case at this early stage. My favorite gremlin is the 'shaders on low-end cards' as the major cause of all performance drains, but we will soon see if this is so as we augment the engine with some aggressive debugging options and extra logging features to really get to the bottom of where the gremlins are hiding!
Work
Aside from the usual tweaks and fixes to make the game creation experience feel a little more together, the last remaining major task for this beta saw some more work, which is of course the 'strange stutter situation'. Just when you think you have fixed it, the issue is reproduced elsewhere. We have done some more work on this today and my final task was to create a small demo for some internal testers to see if we have finally resolved it. The demo requires that it runs at 60fps (or whatever the refresh rate happens to be) but once achieved you get super smooth and silky performance with zero stutter.
We believe the stutter originates from the scaling of the physics universe, and given the not unlimited scope of a 32-bit float you can imagine at the ragged end the accuracy starts to suffer. We have a few ideas more on how we can make a difference in this regard but for now we have used an alternative approach.
Wednesday will also see some work on the store, and the system which brings store items into the main software. Hopefully we have the resources to complete this, AND resolve all aspects of the stutter problem before the next beta release!
