All ideas expressed in this blog are temporal and any resemblance to manifested reality are purely co-incidental. The forgoing is a casual musing from a fellow coder, not an iron clad promise of features and products - The Law
It's the weekend, and I always like to give myself some freedom away from the 'day job' whenever possible, and today I decided to play around with a product we are due to release on Steam before the end of this year called AGK2. It's origins go back a few years now but the principal is simple, which is to allow anyone to create cross-platform applications easily and quickly. Despite the ease with which you can create applications, it remains an extremely powerful and capable language that has been instrumental in producing chart topping apps on both Android and iOS. This blog post was prompted by the arrival of a small box that was mailed to me, and within this package, my first quad core Android device! We have come a long way from the humble (and slow) origins of this almighty operating system and it's exciting to be part of the space that enables the next generation of Android software to thrive and flourish.
In it's brief and unassuming stint in the tools market, AGK has produced some excellent apps and also a few hits too. It's successor promises even more with it's all new IDE for Windows and Mac, significantly faster compiler and a host of new commands and features. It is no surprise that as soon as I received this device I wanted to field test it with an AGK application and test the speed of the device. I was not disappointed, and the shader example which shows off the use of 3D rendering, ran at the full 60 fps on the Android tablet. Rather than a protracted written description of the experience, I have committed by thoughts to video to better illustrate the new AGK and the Acer Iconia Tab 8, Quad Core Intel(r) Atom(tm) Processor 1Gb RAM, 16Gb Storage, Wi-Fi, 8 inch HD Tablet. As AGK already supports x86 binaries, the application is able to run at native device speeds and take full advantage of the silicon.
As you can see the performance is first rate and it's exciting to know that we are now able to deploy to devices that can handle a LOT of 3D rendering, which will open the gates to a whole new wave of intense 3D experiences for portable computing. For more information on AGK, you can visit the official website at WWW.APPGAMEKIT.COM and for news on the current developments of AGKV2 you can visit the forum thread here: http://forum.thegamecreators.com/?m=forum_view&b=41&t=212209&p=0
Spent most of the day improving a central command called INTERSECT ALL which is used by both enemies and the player. The old implementation was good enough, but given it's heavy use and it's tendency to create performance spikes, I decided to implement some better ways of doing the same thing.
The new system first collects all the collision boxes that are touched by the ray, and then sorts them by distance, and only then does it go through the polygons associated with each box. This way I get very early exits when the ray does not pass through any boxes, and a minimal traversal of polygons when it does hit something. Thanks to the internal team for their ideas on this, and it definitely solved the performance spike issues. I was set to do some work on explosion improvements, but the decision was taken to spend two more days on visuals next week, namely TONE MAPPING and AMBIANCE FROM SKYBOX which will combine to create a better light balance in the scene. My minor concern is that both of these might require a small performance hit so it will be interesting to see what the trade-off and benefits are when these techniques have been implemented. The good news is that FPSC Classic had a sort of tone mapper shader, so I will be looking to dig that out as a starting point.
Today I improved the speed of the occluder, added the new occluder sub boxes to The Escape demo entities, and no and behold the saving in drawing less entities to the GPU was EXACTLY the cost of calculating the occlusion. At least it is no more expensive any more! It also means some levels with enclosed levels will see a performance boost, but you will notice a subtle drop if you have a completely open level with nothing to hide behind (naturally). Moved onto defeating the two performance spikes when in high combat. I fixed one which was caused by the enemy calculating too many paths, now they spread that work out. And the second I continue to work on this evening, caused by too many raycasts. Not sure how to solve this, but deciding to spend my brain energy on this rather than a pretty blog. Better blog Friday, and some nice shots :) Going to eat now, then back to the code!!
A full day of driving and meetings today, so I am now truly 'tired' as at 7:11PM (and started the day at 5:30AM). Just enough energy to post a very cool discovery I made last night about the parent of the FPSC Reloaded product. Here is the shot.
This was taken from DAMAGES, Season 4, Episode 9, 45 minutes into the drama. That's right, the console game being played at that point in the story was an FPSC Classic game. A scene in which John Goodman thwarts the machinations of the rogue CIA agent, whilst zombies with futuristic shotguns are being blasted in the background. I could not believe my eyes when I saw this last night, and put a big smile on my face! In FPSC Reloaded news, work continues full steam on Thursday when the occluders will be added to the entities used in The Escape demo level, and once I get my performance boost I will be moving onto my 'integrated Intel graphics' desktop to analyse the engine under GPA Frame Analyser. My guess is that if I use a small enough level, there will be sufficient system memory remaining to run a proper and complete test. Failing that, I might drop a line to Intel and see if they have any ideas to run the more system memory hungry apps using the tool. I must also discover why my test level from Tuesday grew by 174 draw calls, and confirm it was not some rogue code adding dummy objects to the mix (or some setting that had been switched on since the tests of that morning which is probably more likely). In any event, Thursday is the last official day for performance and visuals, and I move into 'third pillar' territories with features such as the entity properties panel and terrain editing tools.
My main triple A task today has been finding and solving the performance spike we see when in high combat. After some VTuning, it was apparent that 25% of the main thread cycles was dedicated to doing a triangle intersection test, which in turn comes from the functionality which casts a ray between the enemy and the player to determine if the player can be seen or hit with a bullet. In play, my framer rate can go from 90 fps down to 25 fps when five characters are running around shooting me, so not ideal.
The good news is that I added some code (and ate 8MB of valuable system memory) to add what I called a 'skipgrid' which remembers the position of the enemy and the destination of the ray and stores what the hit value was. The next time the intersection command is called, I can do a quick look-up to see if this ray was done before, and instantly return the result. I also added code to limit the engine to a maximum of five intersect tests per cycle so this part of the engine does not swallow up other resources. I am sure there will be some after effects of this optimization, but the new frame rates are much improved. In a high combat scenario with five aggressors, there is little to no frame rate drop during the fighting. You do see a drop when you shoot the shotgun, but that's because it has five ray casts being sent out all at once. Most weapons would not exhibit this 'blip' but I will see what testing feedback results first to see if anyone notices this amongst all the other things going on. I am writing my blog early today as I have a meeting with the accountants tomorrow, part of my 'Managing Director' hat. I need time to assemble some paperwork and get my head out of code and into facts and figures. They may appear to be in the same mental ballpark, but games coding is much more fun! Not right now though, it's still full steam ahead and after a nice cup of tea I will be looking closer at the occluder system. If you recall, this is the CPU based system of detecting which objects are being completely hidden by closer objects and removing them from the render scene. You may also recall that switching it on actually caused the frame rate to drop, not increase, so I will be making an assault on that code and finding out the whys and wherefores.
In other news I have my artist back from the land of the ConKit, which means I can start some work on the pistol grip animations, LOD levels for even faster scene renders and other nice graphic tweaks :)
A good day of work today with the morning sorting out a further performance improvement which accelerated the IDE to a nice smooth speed, and I also fixed a bug which restored all dynamic shadows to the editing process. The afternoon was spent adding dynamic shadows to all dynamic entities while in the pre-bake mode. This means we get the visual quality and speed of lightmaps, but when required we get dynamic shadows for things that move.
The last two hours have been spent battling with getting the shadows to filter nicely, and it's now 6PM and I've run out of time. I dug out a few articles on Percentage Closer Filtering but each implementation differs from the way I stage and render my own shadows so it looks like I will need to completely absorb the concept and adapt to what I need. The above shot uses a four sample depth read to fake alias around the edge of the shadow, but there still seems to be a problem with the per-pixel filtering coming out of the pixel shader, the size of the texel offset and perhaps some other icky mystery yet to land on me. I can announce that this new shadow shader, which is attached to the glass terrain system is very efficient and there was no noticeable performance penalty in adding a little PCF so that's good! Work continues on this Tuesday perhaps, but as the quality of the shadow is technically another task, I will have to refer to the master list which has me on a tight schedule! Reloaded Get Medieval On You This was sent to me today and it's a great demonstration of Reloaded in action, and an awesome level design to boot:
Not a lot to report from today's efforts, having spent about six hours out the office and on the road. Did some bits this morning which ticks off one more item, but got an email with five new items based on the latest FPS demo so plenty work ahead of me. The item in question was a pretty exciting one however, and the new weapon system allows guns that use bone and non-bone meshes in the same model. It basically means I have opened the door wider for new weapons to make it into the product via the Store, and the return of one of the great weapon smiths from FPSC Classic! Can't wait to see what he comes up with.
In my absence Rick did identify one issue that remains buried in our default characters which is the way they hold their guns. As you can see, the pistol is not really tightly grasped. Now normally these guys are more in the distance and always moving (and shooting you) so this kind of detail can be overlooked, but it's an interesting question as to how much time we dedicate to solving this over other issues such as adding the material system, e.t.c. The good news is that if we choose to tackle it, an artist can do the work in parallel to me so it will not interfere with the coding time line. After all that driving I am pretty zonked, so have decided on an early night and to slice off some of the weekend to catching up on some coding tasks, and sitting at the top of my list is the re-introduction of dynamic shadows for crates and characters. Using the new glass terrain geometry, I should be able to retain good performance when adding these shadows, but time will tell. I am pretty determined to avoid the 'blob shadow' fall back as I think such effects should remain in the past :)
