Zombies and Terrain Sculpting Day

A day of two halves, with the first half finishing off the Zombie template which is using the new custom character AI system. The zombie is pretty basic, but it's now powered by DarkAI and scripts and someone more worthy than me can continue the work and complete the Zombie pack.

I also sorted all characters so they now use RAGDOLL=1 so ragdolls can now be switched off for characters that do not need or want them.

Right now I am half way through the second part of the day which is to get terrain blending and terrain ramps in the editor. I first tried to do these commands inside the terrain module itself but it was pretty messy in there and would have required some nifty know-how to get it to do what I needed. My backup plan which I am coding now is to do it in DBP which is just as good, if perhaps a few milliseconds slower.  The trick is to snapshot the terrain under the blend cursor and then read height neighbors to create an average, then weight the destination height with an amount modulated by time.  Bottom line is a blend function you will have in V1.009 build, and if time I will be moving onto ramp which is a similar if more complex function for the terrain sculptor.

Been a quick week, and I cannot believe it's Friday already. Meeting next week so have a few days left to make a solid build and ensure everything that used to work still works and the new stuff works well.  For now, have a great weekend!

Custom Characters and AI Meet

Just finished the new system which externalizes the animation frames used in the AI system, so now third party and official character packs can use different animation sets with the central AI system.  A typical example is the Zombie character which in the old version (an aborted build) would not follow paths, but the new one has all the power of the AI system but keeps the custom animations it had:

;anim
animmax       = 1
anim0         = 2552,2603
playanimineditor = 1

;AIAnims (Classic + Zombie)
csi_relaxed1 = 2552,2603
csi_relaxed2 = 2608,2659
csi_relaxedmovefore = 2500,2519
csi_cautious = 2552,2603
csi_cautiousmovefore = 2500,2519
csi_unarmed1 = 2664,2715
csi_unarmed2 = 2720,2771
csi_unarmedconversation = 3046,3094
csi_unarmedexplain = 3105,3155
csi_unarmedpointfore = 
csi_unarmedpointback = 
csi_unarmedpointleft = 
csi_unarmedpointright = 
csi_unarmedmovefore = 2500,2519
csi_unarmedmoverun = 2500,2519
csi_unarmedstairascend = 
csi_unarmedstairdecend = 
csi_unarmedladderascend1 = 
csi_unarmedladderascend2 = 
csi_unarmedladderascend3 = 
csi_unarmedladderdecend1 = 
csi_unarmedladderdecend2 = 
csi_unarmeddeath = 3380,3439
csi_unarmedimpactfore = 3245,3300
csi_unarmedimpactback = 3159,3234
csi_unarmedimpactleft = 3310,3370
csi_unarmedimpactright = 3380,3439
csi_inchair = 
csi_inchairsit = 
csi_inchairgetup = 
csi_swim = 
csi_swimmovefore = 
csi_stoodnormal = 
csi_stoodrocket = 
csi_stoodfidget1 = 
csi_stoodfidget2 = 
csi_stoodfidget3 = 
csi_stoodfidget4 = 
csi_stoodstartled = 2861,2904
csi_stoodpunch = 2775,2848
csi_stoodkick = 2916,2969
csi_stoodmovefore = 
csi_stoodmoveback = 
csi_stoodmoveleft = 
csi_stoodmoveright = 
csi_stoodstepleft = 
csi_stoodstepright = 
csi_stoodstrafeleft = 
csi_stoodstraferight = 
csi_stoodturnleft = 
csi_stoodsubtleturnleft = 
csi_stoodvault = 
csi_stoodmoverun = 
csi_stoodmoverunleft = 
csi_stoodmoverunright = 
csi_stoodreload = 
csi_stoodreloadrocket = 
csi_stoodwave = 
csi_stoodtoss = 2981,3034
csi_stoodfirerocket = 
csi_stoodincoverleft = 
csi_stoodincoverpeekleft = 
csi_stoodincoverthrowleft = 
csi_stoodincoverright = 
csi_stoodincoverpeekright = 
csi_stoodincoverthrowright = 
csi_crouchidlenormal1 = 
csi_crouchidlenormal2 = 
csi_crouchidlerocket = 
csi_crouchdown = 
csi_crouchdownrocket = 
csi_crouchrolldown = 
csi_crouchrollup = 
csi_crouchmovefore = 
csi_crouchmoveback = 
csi_crouchmoveleft = 
csi_crouchmoveright = 
csi_crouchmoverun = 
csi_crouchreload = 
csi_crouchreloadrocket = 
csi_crouchwave = 
csi_crouchtoss = 
csi_crouchfirerocket = 
csi_crouchimpactfore = 
csi_crouchimpactback = 
csi_crouchimpactleft = 
csi_crouchimpactright = 
csi_crouchgetup = 
csi_crouchgetuprocket = 

As you can see, custom character models will NOT have all the animations the AI system requires, but I will be tweaking the system so it can skip an action if the corresponding animation is unavailable.  It's another way for artists and content creators to shape the behavior of the enemies from with the FPE file :)

The current character model has a little trouble holding the pistol in V1.0085 so we have improved it for V1.009. It's not PERFECT yet but it's a little better than the floaty version it replaces.

Ending on a lighter note, during my work on replacing the hacked internal animation values, my enemy decided to do a swan dive for me.  Thought it was quite amusing, and quite an unexpected attack from my enemy!

Friday sees the work begin on the terrain blending and ramping, which has been a long requested feature and so I am looking forward to seeing what I can do. Watch this space for some terrain magic :)

What A Day

Spent half the day on what I term an 'Epic Fail' task, which was to solve the issue of an X file loading in but having an animation issue. When I see this from my own art, I often ask the artist to correct the issue, but the engine will need to handle MOST types of X file which means solving this one. Alas after four hours it remains a mystery, so I decided to continue my main list and sort out custom animations for the AI system.

This also turned out to be a pig as I had to manually extract ALL the hacked in animation frames and create a new way to store them externally, and ensure the system did not break in the process. As at 5PM I am half way through this but at least the end is in sight and viable, unlike this mornings coding pain.

Once I have the custom animation frames externalized, I can then bring out the Zombies, Elephants and Robot Waiters to test the functionality, which is basically allowing ANY custom character to follow waypoints and obey the clever systems built into the DarkAI module.  Hopefully Thursday will see it in a form that I can test and refine.  Until then...

Material System Done

With visuals, performance and AI for the moment sorted, my task for today was to get the material system up and running. It's now just gone 3PM and it's done. We can now shoot different materials and get different decal animations and sounds, when you walk on wood, metal, stone or other material the correct footfall is heard. Now when you walk on the roof, no more grass sounds!

I gave myself a day and did it in just over half a day, so I am moving swiftly onto my next task which is getting Zombies working with the AI system. By this I mean have a new look-up table of animations that the AI system will use as part of the 'main' character system. Not only will this breath new death into the Zombies but it also means custom characters can use the path finding and LUA logic treats of the full character system, so no need to script 'everything'.

This next one could take an hour or a day, but I have budgeted a day to ensure it also works with the wider requirement of custom characters, which means digging a few of the custom characters sent to me out the folder and ensuring they work fine.  Still, happy report a good day done with a few hours to spare!

More Aggressive, More Speed, More Damage, More Fun

Finally worked out why the AI was so 'distracted', and put it right. The latest Escape demo is now populated with mean sons of guns who like nothing better than to hound you into extinction. 

I also spent my Sunday on the project as well, with improvements in what I am calling the light balance of the scene. Now all element such as static entities, dynamic entities, terrain, characters and other bits use the same calculation for both ambience and direct sun lighting.

As you can see, with ambience only you get a general coverage which all elements in the scene agree with, plus the shadows which are factored in.

In this direct lighting shot, all ambience has been removed so you can see the surfaces that have a direct line of sight to the sun (again, shadows factored in as they work in a slightly different way).

The final composite which adds the two together is the white matt surface on which the texture colour is eventually applied.  The weapon is deliberately brighter as the textures on the guns are a little darker and has additional visual effects such as cube mapping applied and tends to lower the overall luminescence of the weapon models.

I also discovered that some SSAO coding in the bloom shader was not actually doing anything, so I removed this and gained an FPS boost from 84 fps to 90 fps which was nice. I have lost the subtle blurring I got from the NINE texture reference samples, which might introduce some anti-alias effects, but I am sure there is a new technique I can try which does not cost that much more than the standard bloom shader.  I am not ruling out a screen space ambient occlusion trick in the future, but right now I am all for performance and more honest visuals, and removing it felt like a step in the right direction.

With the great victory of new faster, more FUN enemy AI, I am now moving onto one of my pet peeves which is the ability for characters to enter and logically track a player through a building.  That is, a single entity which is subdivided into walls and other vertical obstructions. Making a building out of individual wall entities already works fine, but most single entity buildings currently act like a huge obstacle that the enemy must run around. Nice effect when you want them outside, surrounding you, but for the most part you want to be able to run inside a building and be chased inside!  It could be an hour or a day, but today is the day this task gets my undivided attention!

It's Picture Friday Hurray

Rather than a protracted text blog, I thought I would make a picture blog as a Friday treat showing last night's and todays work. The first one is a nice shot of my running towards the rocket man for some AI testing.

This next one is an experiment I did last night to study the artifacts when only direct lighting is used. As you can see, there are numerous issues that go unnoticed when add ambience and textures on top of this.  The terrain is not consistently lit when compared to the buildings (or vice versa), the shadows on the building walls are 'odd', the sandbag and log in the foreground should not be black, and so forth.  Normal map on the weapon and character look great though!

Had a little fun with ragdoll earlier, and decided to snapshot this pose to remind me that we still need to look at ragdoll death sequences some more.  Looks like he died listening to some terrible music.

And finally, a shot that almost looks better than if it was textured, but also shows that the lighting could be balanced more when you compare the terrain and gun to the entities.  Just needs a few tweaks and then I can bring back the textures are spend a little time looking at the texture side of the coin (texture stretching, shrinking, artificial lighting, e.t.c).

Been a long week, with not too many hours of sleep to be found, but I am happy with the progress, and with the explosions now integrated I can move onto some new functionality next week. I also helped Ravey get his multiplayer prototype further integrated to the main engine, which means I can leave him to it now as he had everything he needs for the moment.

Until next week, enjoy your weekends and hope you all get some nice weather! No chance of that here in Wales, but there's always hope :)

A Full Day Of Integration

Today was the big Multiplayer Integration chat day, in which I get educated how the multiplayer side is working and Ravey gets educated about how the single player resource engine works.  From this we can create an integration plan that reduces mistakes and increases productivity, resulting in a quick turnaround for seeing multiplayer in the main engine.

It took eight hours but we covered all the bases and the plan is now in place. We will be adding some new Multiplayer Start Markers to the IDE and the ability to load in 'bolt-on' entities for the Uber Character that we will need to represent the mutliplayer characters, which will need the ability to wield all weapons and be created dynamically when the game is initialized.

I was set to integrate the new explosion into the engine but the chat has thrown up three key tasks that I need to implement so that Raveys multiplayer engine can hit the ground running.  Hopefully it will not take the whole day which means there is a good chance of explosions before 4PM on Friday!

Simon continues a pace with the ConKit and integration has already begun, which should result in the buildings being consolidated on the spot, meaning a building that takes thousands of objects to represent turns into one object comprising just a few meshes and possibly a single texture set.

Also Rick did a critique of the latest Escape Demo level, and could only find two things to wine about so progress steady on that score!  Apparently the enemies are not aggressive enough so hopefully will find some time to turn up the volume on their hate-o-meter.  If the enemy AI does not present a great battle experience, we will suffer for it when the product gets released and we have the time to get it right, so we should make it a priority.

Visuals and Explosions

Spent the day on smaller tweaks to get the Escape Demo level further along to ensure the best bits remain and the worst bits improved.  It's looking much nicer now, plays faster and hopefully a few extra functions can be added before we're ready for the public beta release.

Also wanted to repeat something that was posted in the comments, and also to clarify that all the shots from the last few weeks have been on LOWEST settings only. That means no normal maps, no specular, no real-time shadows for entities and none of the extra finesse that can be spent with a high end shader. My goal was to get it playing fast and looking good at the lowest settings, and then I can re-introduce the higher end features as I move up the food chain. This way the visuals will remain consistent and use the same light balancing no matter which shader technique you choose.

Right now I am finishing off the integratable prototype for the new explosion system that is finally going in to replace the one we are currently using. The current explosion is a bit 'epic' right now, and probably needs scaling down but I can go that once it's in game and I can get a sense of scale. The new explosion is pretty cool though with two fire decals, two smoke decals and two debris effects based on physics particulates.  Looks good in the lab so should look great in game, with the only obstacle being the reduction in what we call the intersection issue (a flat camera facing plane cutting into another surface at an angle and creating a strong line contrasting the explosion decal and the scene).

I have also freed up and de-prioritized some task items to preserve the original functionality list I had a week ago, which include enemies inside buildings, material system and cleaning up the entity property fields so they are 100% relevant to the engine (a long time coming).  As much as performance and visuals was challenging and fun, it's nice to do other things now and again, as a change is as good as a rest!

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.

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.

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

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.

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

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.

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

Performance And Percentage Closer Filtering Fun

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:


https://www.youtube.com/watch?v=S4LaB2J1YSM&feature=youtu.be

Virtual Reality in AGK V2

Also came across this one in my inbox too, and after I stopped grinning my face off it sank in that Android and AGK have come a long way.  Notice the 360 degree freedom of the cardboard VR, even Oculus DK1 could not do that :)

https://www.youtube.com/watch?v=rD05Iwh1ZDM&feature=youtu.be

The Floating Gun Trick!

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

Third Party Speed Reports and Waste Twist

Been an interesting day, starting with some great FPS reports from the field. I sent a build of The Escape demo to some internal team members and the report from one machine shows the V1.0085 version running at 32 fps and the new version running at over 90 fps, so we've definitely made a substantial improvement in performance (for some levels).  

Aside from building versions for internal usage, I have spent most of the day writing a small prototype which allows me to manually adjust the weapon direction of the character at various waste twist angles. It's not as straight forward as rotating the X or Y axis as the spine of the character is angled in such a way that such simple interpolation fails miserably. The curve is not linear too, which meant I needed to write something that allowed me to manually tweak the spine angles for each of the angles the character could twist, both left and right. The engine now has 36 entries based on how much the character twists around to shoot while strafing the target, and then I smooth the transition between the two closest sites.  The result is pretty good with a more human, less robotic twist to the character.  The good news is that writing the waste tweak editor and adding it into the game did not take ALL day, which means I have a few hours left to work on some small artifacts that have creeped in while I was distracted with performance.

My plan is to start the first of my major tasks on Friday, which according to my most current schedule is restoring dynamic shadows to the PRE-BAKE system for things like crates and characters (initially using the new glass terrain geometry to retain the performance we have now).  It will be part of my daily paranoia that each functional item I put back in does not adversely affect our new found performance metrics!  Until Friday...have a nice evening!

Meeting Day

A successful meeting day today with both visual and performance objectives reached, and a new set of tasks for the next 3-4 weeks agreed.  The good news is that I have another week to work on performance and remaining visual touches so hopefully I can get some more out of the engine before I move onto the bulk of the next month of work which is what I am calling the 'third pillar'.

My ideas was that three pillars hold up a good product, the performance, the visuals and the functionality. Visuals and performance have had their weeks in the sun, and good things came from it. The last pillar, that of functionality, will focus on adding those features to the software that we felt are critical, and agreed an order in which they should be done. I cannot remember the order exactly due to two pints of Guinness, but it includes extra terrain editing controls, multiple levels, improved explosions, melee combat, the material system, importing custom characters into the AI system (for Zombie fun) and a bunch of IDE clean-up tasks. The result is a piece of software that will closely resemble it's final shape on Steam (minus the CONKIT and MP).

I prepared some side by side shots for the meeting but never used them, so I am posting them here instead so the effort in making them was not wasted.

Hopefully I don't need to explain which side is which, but you will be pleased to learn you get this extra visual eye candy in addition to a jump from 40 fps to 60 fps (which is a sizable jump at these speeds).

I also took the demo to the Ultrabook to profile with Intel Frame Analyser last night but after about five hours, I discovered that it would crash the app unless my app used only a little amount of system memory. If I used a lot, so did the frame analyser, and it would bomb out.  My new plan is to analyse something like Get To The River level which uses a lower system memory amount and I can study the GPU side of things and understand what in the scene is consuming SO much processing.

My task for this evening will be to continue pushing the odd wires back into the engine so it does nothing naughty under regular use, such as not removing a lightmapped object when one is deleted in the F9 edit mode.  Before I crack on with the next series of major tasks, getting what I have done so far squared away with nice commented code and a clean desk is a good way to prepare for the ordeal to come.  I also have the 'multi-core lightmap crash' issue to investigate as well, which will need to be sorted in order to accelerate the feature of lightmapping the test game on the fly.  Looking good so far though, and I am very happy with the work from the last two weeks.

Another One Bytes The Dust

Today was officially "make the demo work nice" day, but I decided to do one last performance tweak before I started on the main purpose of the day, which was to replace all the GetParameterByName function calls with pre-searched handles for all shader constant calls. Turns out this little pearl moved by frame rate from 78fps to 90fps. Another small win for the performance camp!

My main mission was to get the lightmapping baked and working in a fast new version of The Escape demo. Of course it's never plain sailing and I am getting double-object flicker and completely black objects appearing where there should be nicely baked visuals.  Determined to stay here until a solution has been found, but with a little luck and plenty of determination, I will get there.

Big meeting day tomorrow so once the demo is up and running, going to sort out the rest of the bit tasks, clean the office a little and try to get an early night. This plan all depends on some fast work now..so I think it's time for less blog and more code!  Will report on the meeting highlights on Wednesday.

Amazing Community Video Of Reloaded 1.0085

Had to start my blog immediately after seeing this video from RETRO GAME BLOKE, proving once more that the community can often find ways to do things that the guys who wrote the engine thought was impossible.  In his video, you will see demonstrations of a third person body that animates as the player moves, and the ability to pick up and drop items. Both of these features are not native to the engine, they have been scripted with the built-in LUA commands and has left the lead programmer of the Reloaded project wandering how the 'smeg' it was done:

https://www.youtube.com/watch?v=xLGbVhBXr1M&feature=youtu.be

Not to mention the dynamic in-game scaling!  I am officially gob-smacked, and it's great to know the performance issue is not slowing down the community when it comes to creative ideas!

As mentioned last week my main thrust of performance work ended on Friday and the two days this week before my meeting on Wednesday is about cleaning up and putting the wires back in the box ready for a demo to the internal folk. First news is that The Escape used to run at 35-40fps on my machine, and the same settings on my machine now run at 65-90fps.  It was no one thing that fixed it, and you can re-read the blog posts from last week to get clues what was improved, but my personal milestone of playing the whole game and staying over 60 fps has been achieved (phew).  I then decided to have one more day on performance before the clean-up, which I estimate should not take more than one day if I am focused.  This meant I could tackle one or two more ideas I had, including a look at the cost of shader effect swaps, texture reference costs, the true cost of batching and general behavior of the engine.

An Intel engineer put me onto a tool called GPUView which I assume has been used for YEARS in the industry but news to me (naturally). It clearly shows the work the CPU and GPU are doing in broad strokes (actually it's shown in hideous detail but it provides some nice charts that can illustrate the activity of the app quite quickly).  It clearly showed that the app is indeed GPU bound (that is, the engine is spending a LOT of time waiting for the GPU to finish what has been sent to it), and also that the CPU spends a good deal of time sitting around waiting for the GPU to flush sufficiently that more render instructions can be sent.  I am still not 100% proficient at reading all this new data, but it's great to have my fingers on the various pulses of the engine now.

The last big 'investigation' on my list (aside from object occlusion and render draw order which did not get actioned) was to find out if the terrain system (which is notoriously slow thanks to a huge shader) could be increased in speed. The above scene in the version from this morning ran at 135fps with all features switched on.  Not bad compared to V1.0085 speeds, but when I switched to a re-written LOWEST shader to use only a single surface texture (no painting, no normals, no triplanar, no vegmap, no shadows), I jumped to 225fps.  It was clear in my cut and paste analysis that each texture reference added to the terrain shader knocked another 20-30fps off my total.  For a proper analysis I would need something like Frame Analyser or NSIGHT now, but it's revealing to know where a huge performance chunk could be found!  The reason I switched to one texture is that I had an idea to implement something called Texture Splatting which would render a local texture of my immediate area to a render target and then use that as my single texture in the shader. My theory is that rendering textured quads was faster than the seven million texture reads I am doing every cycle, which works out at 438 million texture reads per second at 60fps. Pity there is no time left to implement the idea, but it's very tempting to know that implementing it could give me between 40-80fps extra in some situations.

My actual tasks for today include a final test of the batching system, correction of a crash that only happens after 2 hours of lightmap baking (a horrible one to reproduce) and restoring the dynamic shadows for the editor and higher shader modes.  It's plenty to be getting on with, and is a needed step to ensure the engine stays in one piece.  It's all to easy to break everything to get more speed, but it has to be tempered with ensuring the foundations are still in tact, and that everything that worked before, works still.  Hopefully I can argue for more performance work at the meeting on Wednesday, but with my goal of 60 fps achieved in The Escape demo, and pre-baked lighting in place to improve the visuals of the scene, I rather suspect the vote will be to move to the 'third pillar' which we have dubbed 'functionality'. That is, stuff like more LUA commands, grenades, better explosions, a fully working entity properties panel, finalized widget graphics, the list, as you can imagine, goes on :)

Final Week Day On Performance

Well I've had a week, and I've crushed some bottlenecks and got my demo from 35 fps up past 60 fps which was my goal.  Today is about putting everything back together now so the software has no wires hanging out before the weekend. That means adding a PRE-BAKE vs REALTIME slider panel drop-down so we can choose between the old way and the new way.  Making sure the editor and test game can work as it did before, and also that I can lightmap any time I want when I press F1, that the levels save the lightmapping work and reload it perfectly every time, that it can handle The Escape demo without crashing (all be it on a single thread which causes test game to freeze while the lightmapping is in progress), plus fix an issue that has just emerged in the IDE which is now slowly than it used to be, so that needs investigating.

Also been experimenting with quality settings, with the above showing a quality setting of 2.0 and the one below showing the setting at 0.5.

The effects are so subtle I decided to change the default lightmapper to 1.0 for the moment and come back to the degree of effect the quality value provides.

I have also added a new PRE-BAKE vs REALTIME slider panel drop down box which lets me bounce from these two modes, and I invite you to guess which one is which between the one above and the one below.

Perhaps a little unfair as I still need to line up the intensities of the scene, but I am planning something very specific in this respect mid-October.  Still plenty of performance work I 'COULD' do to the engine, but my week is up and I will be making a case at the next strategy meeting to do some MORE performance work, especially on the GPU side using the GPA Frame Analyser, and perhaps a little NSIGHT as well.  My task list still shows render ordering and object occlusion work as priority items, but it looks like I have run out of time this week. I still have two more days next week before the meeting so more progress on performance still to come.  Pretty happy with this weeks work however, from all the team, and quite buzzed to repeat this next week too!  

Until then, enjoy your weekend and if the sun is shining, try to pry yourself away from the keyboard and go for a nice walk.  At least that's my advice to me, whether I take it or not is another matter.