Tuesday, 21 October 2014

Shot Of Latest The Escape Demo

Here is the latest shot to compare with one provided a few blog posts ago, but this time with the subtle bounce light from the ground lighting (notice the slightly green colour under the plank sticking out of the building).

More generally, having this extra bounce light in all the shaders (both sky and floor colour) is like having two extra lights on everything. It's subtle, but it does not only lift the scene but blends them altogether with a common colour theme, especially with the red, golden and darker skies!

Here are the settings I am using, but as with many things during beta development, if I change the shader levels all this could change again :)  Don't worry about the 34 fps, the whole software slows down when all the slider panels are on (something to do with drawing each slider bar bit by bit).

Currently tackling a rather fiendish problem resulting from the terrain system not producing super-accurate LOD0 mesh versions of it's segments, meaning my glass terrain geometry can sometimes be cut by the real terrain. Boo!  I have a few ideas along the lines of building my own glass terrain meshes from the height data, but first I am going to tinker with the built-in one first. It only happens when two segments meet, so that's my clue and my way in.

Currently riding high on the SLANT survey for "What are the best game engines for non-coders?". Why not check out the list and vote for your favorite here: http://www.slant.co/topics/1907/~what-are-the-best-game-engines-for-non-coders

A question also came up and worth bouncing out there. We now have different weapons coming in, and they have different 'hand' models.  If you are doing a game which uses different weapon sources, do you care about the hands changing from 'gloved' to 'ungloved'?  If so, do you have any ideas how we could tackle this without making artists lives hell?  Food for thought.

Monday, 20 October 2014

Automagical Exposure And Spherical Super Fudge

Today and tomorrow my schedule budgeted in the time to work on some kind of tone mapping and also the addition of skybox ambience. After some researches over the weekend and a little this morning, it turns out for true tone mapping I need implement a whole HDR system and for skybox ambience I might have to add an extra cube-map texture read to all pixels!  The upshot will be to improve the visuals still further by defeating the over-bright scenario we have been seeing and also to improve the general lighting of a scene full of differently textured objects.

A typical unlit scene - the starting point for all rendering

Alas I am not prepared to delay the project further by implementing a whole HDR system as it would require a lot of texture and shader updating, and adding texture referencing in my shaders is the last thing I want to do after making such good strides in performance. The solution was to achieve everything I wanted but without using the above techniques. As at 2:30PM I have achieved these goals, and am ahead of schedule by a day :)

The solution to the tone mapper was what I am calling my auto-magical exposure feature, which is very similar to adaptive bloom and acts on the post process shader to ensure a scene compensates for being over bright. Added some code to use the time delta from the engine and it now adjusts at the same speed as the human iris which creates a nice subtle effect.  Look at the sky and your eyes adjust, look at something dark and the eyes adjust again, look back at the sky quickly and notice how the eyes adjust over 1-2 seconds.  Very cool!

The second solution was to dump reading the skybox (even a small 1x1 per side version of it), and simply pre-scan the colour of the sky and the colour of the floor, and load those directly into the shader as a constant. I then use a spherical harmonics trick to work out the contributions based on the surface normal presto, the ambience now has the visual effect of receiving bounced light.  It's not sophisticated, but it's completely free and super fast!

Notice how the ambience is taken from the sky and terrain colour

When combined with the remaining pixel shader it blends with the scene

Next on my list is to read an avalanche of links Rick has sent me on spherical harmonics (as there might be a test tomorrow). Then I fix the Rocket-man, who has been doing very silly things with his rocket and needs sorting.  If I can do all that and have a build for 4PM then I think that would be a good first day of the week!  I am eager to get past the performance and visual stuff this week as there is a big chunk of third pillar functionality such as the material system I want to get my teeth into.

Saturday, 18 October 2014

Android & AGKV2 - A Powerful Combination For Developers

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

Friday, 17 October 2014

Improved Ray Cast Command

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.

Thursday, 16 October 2014

Occlusion Faster, Spikes Under The Crosshair

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!!

Wednesday, 15 October 2014

Famous At Last!

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.

Tuesday, 14 October 2014

Combat Speeds

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 :)