Well another high octane day of development boxes being ticked. Rather than one of those nice blogs with pictures and things, here is a massive rant with lots of pearls buried inside. We integrated the LUA and DarkAI modules today (or rather last night thanks to Ravey Night Owl) so that we have the basis of shifting all hard coded AI calls into the LUA script and making things MUCH more flexible. We briefly investigated the Channel 3 headphone sound issue, but was unable to find the cause so Simon has a mission to find more information before a fix can be made. We might have found a new character artist for our team, so more on that when we have tested the water and have something to show you. Added three new fields to the Player Start marker called 'Regenerate Rate, Regenerate Speed and Regenerate Delay', I will leave the purpose a secret but I can tell you it has something to do with health. Added a slider to the occlusion system so you can control how many polygons are chosen for the occluder render, which MASSIVELY improves performance as you dial it down to the scene you are working on. More optimizations possible but it's great to know we can leave this in and have you experiment with occlusion to get a good performance balance. We will be keen to learn your results from this in the next build. We replaced the redundant LAYER: status bar prompt with EDIT: which now tells you which IDE edit mode you are in, such as FULL or INSIDE, where INSIDE is a special new mode which lets you place smaller entities inside larger entities such as buildings. Added more flinch to enemy limbs when shot, we will see if this looks okay, or real bad. No more water sound when you die underwater and respawn at the checkpoint or start position. Shadows no longer disappear when objects are occluded from the cameras perspective. New models caused some new occlusion issues, but they where quickly solved. Created a new very small test script for the AI work to be used with a new Combat prototype which will allow the rapid development of the character AI, and even non-character entity logic AI too.
Finally, we briefly looked at creating a PVS (potential visibility set) system from the occluder to remove all real-time occlusion calculations and gain even more run-time performance but it would have taken 100 hours to bake the PVS data, so we decided not to add that 'feature' for now :)
Wednesday, 30 April 2014
Tuesday, 29 April 2014
Software Occlusion Now Integrated
Lots of tweaks happened today, including Dave's completion of the CPU software occluder which is now working inside the main engine and culling objects left, right and everywhere. Added an extra control to SETUP.INI to control how many polygons are selected for the occlusion geometry which will help lower end systems use occlusion to suit their performance limitations. Also saw some good improvements to the weapons, making them feel a little better. My own work involved solving the issue of why the latest build did not run on some systems which turned out to be a stray debug DLL dependence, new code to control entity speed for non character entities so that the speed you see in the editor is the same as that in the game and perhaps my favorite completed item was the alpha slice in the editor which will remove the roof from buildings, and disable them from selection when the TAB is pressed to engage the mode which allows you to place tables and objects inside the entity building rooms. You will wonder how you managed before this extra little feature. Just zoom in, press TAB, select some furniture and start decorating!
Fixes from yesterday include enemy flinching and extra spurting blood when enemies shot, entity editing mode back into the F9 mode, strange 'grey screen' issue reproduced and fixed, muzzle flashes now line up with the gun no matter the FOV, improved fogging technique above (and below) the water line, reduced accuracy when shooting from the hip for default weapons and a few other minor tweaks to bring things closer to completion.
Due to a very insistent Ravey, I also added (actually re-instated HEADLIMBS field in the FPE) the head shot feature which will provide a X4 multiplier for any bullet that hits the head of any character. Combined with the new feature which recovers from iron-sight the moment you release the Right Mouse Button, you get a much better sense of combat. We also removed the ability to sprint and shoot at the same time, and when you put all these things together you get a much cooler game play experience. Obviously lots more to follow, but it's starting to take the shape of a serious FPS mechanism. Finally, we also fixed the annoying issue of running through the edge of the gate entity, so that now the physics shape lines up perfectly with the visible object geometry. A small but vital fix for this version.
We all have a myriad of tasks assigned for Wednesday, but my main task assigned will be the start of character ragdoll physics. I have budgeted a day but with the usual distractions it will probably leak into Thursday too, but the time has come when it becomes my sole task. The good news is that I have done ragdoll twice before for FPSC projects so third time should be a charm! I am not aiming for the full Monty ragdoll on this occasion, I will be looking to create a convincing 'fall over dead' simulation for situations when the enemy expires and falls up/down/off a hill, or over a crate or entity wall, or from a very high tower, or down some spiral stairs, or into the water, or in the middle of the sky. It's a lot to handle, but it should be fun to code and even more fun to test! If anyone wants to post some inspiring ragdoll YouTube footage to get my brain in the mood for some good ragdoll coding, post here and fuel the old fire.
Fixes from yesterday include enemy flinching and extra spurting blood when enemies shot, entity editing mode back into the F9 mode, strange 'grey screen' issue reproduced and fixed, muzzle flashes now line up with the gun no matter the FOV, improved fogging technique above (and below) the water line, reduced accuracy when shooting from the hip for default weapons and a few other minor tweaks to bring things closer to completion.
Due to a very insistent Ravey, I also added (actually re-instated HEADLIMBS field in the FPE) the head shot feature which will provide a X4 multiplier for any bullet that hits the head of any character. Combined with the new feature which recovers from iron-sight the moment you release the Right Mouse Button, you get a much better sense of combat. We also removed the ability to sprint and shoot at the same time, and when you put all these things together you get a much cooler game play experience. Obviously lots more to follow, but it's starting to take the shape of a serious FPS mechanism. Finally, we also fixed the annoying issue of running through the edge of the gate entity, so that now the physics shape lines up perfectly with the visible object geometry. A small but vital fix for this version.
We all have a myriad of tasks assigned for Wednesday, but my main task assigned will be the start of character ragdoll physics. I have budgeted a day but with the usual distractions it will probably leak into Thursday too, but the time has come when it becomes my sole task. The good news is that I have done ragdoll twice before for FPSC projects so third time should be a charm! I am not aiming for the full Monty ragdoll on this occasion, I will be looking to create a convincing 'fall over dead' simulation for situations when the enemy expires and falls up/down/off a hill, or over a crate or entity wall, or from a very high tower, or down some spiral stairs, or into the water, or in the middle of the sky. It's a lot to handle, but it should be fun to code and even more fun to test! If anyone wants to post some inspiring ragdoll YouTube footage to get my brain in the mood for some good ragdoll coding, post here and fuel the old fire.
Monday, 28 April 2014
Things That Make A Coder Chuckle
I have been banned from posting videos and shots that do not compliment and preserve the integrity of the Reloaded brand, but sometimes you just have to laugh at in-development moments.
The task in question was a new flinch system which would show the limbs of the character twitch when shot, to give you some idea of which limb you struck with the bullet. It's very experimental, and it will be better than having nothing, and I am sure I know ten better systems to use instead but they all require weeks of fresh development which I don't have.
What you see above is the cruel result of me shooting each foot of the character and finally his upper leg. The quick test code to check the limb detection was to randomize the manual limb matrix on top of the animation data for the struck limb.
The bit which made me chuckle is that using the pistol means it takes several shots to kill a character, and during the fire right the enemies contorted into an array of hilarious postures including walking while one leg high in the air, lower leg completely missing, head bent back into the spine, both arms crossed at extreme angles, and every other mutation you can think of. I figured I would stop and blog this curious moment before I carry on and replace the test code with something sensible. It's times like this I wonder whether leaving this code in would produce a more popular product than deleting the hilarity and adding the rather predictable reasons we have come to expect from FPS games. Such is a day in the life of the games developer!
Plenty tweaks done already today, but will report a good list in Tuesday blog which we have racked up a few more items to show off :)
The task in question was a new flinch system which would show the limbs of the character twitch when shot, to give you some idea of which limb you struck with the bullet. It's very experimental, and it will be better than having nothing, and I am sure I know ten better systems to use instead but they all require weeks of fresh development which I don't have.
What you see above is the cruel result of me shooting each foot of the character and finally his upper leg. The quick test code to check the limb detection was to randomize the manual limb matrix on top of the animation data for the struck limb.
The bit which made me chuckle is that using the pistol means it takes several shots to kill a character, and during the fire right the enemies contorted into an array of hilarious postures including walking while one leg high in the air, lower leg completely missing, head bent back into the spine, both arms crossed at extreme angles, and every other mutation you can think of. I figured I would stop and blog this curious moment before I carry on and replace the test code with something sensible. It's times like this I wonder whether leaving this code in would produce a more popular product than deleting the hilarity and adding the rather predictable reasons we have come to expect from FPS games. Such is a day in the life of the games developer!
Plenty tweaks done already today, but will report a good list in Tuesday blog which we have racked up a few more items to show off :)
Saturday, 26 April 2014
Belated Blog
Friday was mostly a day of 'further work' which included adding some helpful text to the download system to inform new users what to do with the dialog. More great progress on the software occluder and a video from Dave at the last hour shows just how cool it really is. I am going to postpone showing you guys any of this until it is in the engine I can reveal some real metrics and how much performance you can expect to gain in different scenarios. My own coding antics have been to strip out an AI module and create an integratable prototype so Dave can start the character AI work in earnest next week. It meant I had to remove my clever staircase, ladder, container and hard coded combat logic from the engine, but it also means we have a relatively blank canvas on which Dave can work his magic. Dave has been a games developer as long as I have, and his passion has always been 'games' creation, and unlike me, has continued to play all the best games over the years. He's the go-to guy for ensuring the game play is top draw and my work will hopefully allow him to focus on behaviors rather than the boring stuff like animation and movement. During the strip out of the AI module, I have left in the clever stuff that is still relevant which allows the characters to move and animate in a controlled way, so that foot planting is perfect and all the extra moves such as ducking, crawling, leaping over things combine animation and movement in a single system. It means when Dave's AI system wants an enemy to jump over a sandbag, dive for cover, throw a grenade and run like hell, it's just a few flags! We also sorted more player water interactions so that you can 'sort of swim for a bit', but slowly sink, then your head goes under water and you start to drown slowly. This will be the initial implementation until we explore water properly with underwater scenes, diving, exploring, e.t.c. A pretty packed end of the week and the following week should prove the best yet as occlusion goes in, DarkAI moves to LUA and LOTS more tweaks happen!!
Thursday, 24 April 2014
Preparing the Ground For New AI
It was decided a while ago that a new person should be placed in charge of the scripting and AI modules, and that they should have a lot of time to stay on the subject as we refine the game play experience. To this end I am in the process of removing all the complicated super-clever AI code that did not really work and revert the system to something simpler than can be adopted by a new coder. I am also moving all the hard coded decisions such as whether a character is in PATROL or COMBAT mode into a LUA script which will allow end users to fully customize the experience. I may lose a few performance ticks using all this byte code logic, but I think it will work out for the best, both for the internal team and for the software overall. Step one is to reduce the character to two simple behaviors, which is to walk a patrol along an assigned waypoint and to attack the player when they get close enough. This will involve the introduction of quite a few LUA script commands to achieve, but it also means a myriad of permutations are possible once these basic behaviors are working in the engine. It's not a quick task, and Rick was happy to berate the whole team for not checking in more 'DONE' items on our internal spreadsheet from today but we are entering a phase of some large multi-day items now and so we will get days like these. The good news is that the result will be a very customization logic system for characters and pretty much any entity too!
Wednesday, 23 April 2014
Hitting The Ground Running
Work
Was so absorbed with the schedule, emails, tasks and delegation on Tuesday I completely forgot about blogging. I am here to rectify that a little and list out the stuff we have done in the last two days.
Changing the grass in Test Level is now instant, and no longer takes an absolute age. Added a MEDIUM technique to the entities to allow cheaper shadows along with the flash light effect. We extended the grass drawing range and made the grass fade out better so no more grass popping out of nowhere. The superflat terrain flag now handles the cheap shadow system properly allowing this method to be used for levels where terrain is not needed. It remains to be seen if we promote this feature to a slider/tickbox or keep it hidden in the SETUP.INI. The aspect ratio is now respected no matter what resolution you are running when in edit mode, which means perfectly circular cursors and scopes on rifles :) Fixed the issue of collectible weapons in standalone games not showing the guns when collected. The download system can now determine if an entity has been updated by the artist, and trigger the update to download automatically. Just log in each day, click download and if your purchased items have an improvement, they will be downloaded automatically. Added better interaction between water and entities so they bob about on the surface or sink to the bottom, no more jiggling about erratically. Added F10 reminder on the start-up prompt to show new users how to grab a screen shot from the Test Level session. The engine can automatically detect if an X file is NEWER than the DBO that represents it, and if so, replace it with a new one. This ensures the best performance via DBO and no further need to keep deleting DBO files after each update. Save standalone now remembers all settings in the root SETUP.INI allowing your executables to be exported just how you want them, no more manual editing each time. Skies, terrain and vegetation grasses lists now update each time you run Test Level which means you can buy a sky or grass choice, download it and then run the level immediately to try out your new item without needing to reset the software.
I also did half an hour looking into why the old DBP Free Version suddenly stopped allowing activation, which turned out to be a decent PHP version upgrade which messed up the security at our end. Paul came to the rescue and solved it in short order. New DBP users are happy once more!
Had a meeting today and refined the final list for the next version even further. We have isolated the most important features that the engine sorely needs and are working hard to get them working quickly. To give you a hint, it involves heavy coding of the AI, scripting, Windows 7/8 compatibility and a myriad of tiny yet essential tweaks to make the editing and playing of games enjoyable. Now we have a good upload system and a Game Creator Store administrator in place, expect to see items appear on the store in the coming weeks so don't be afraid to click the FPSCREATOR button in the bottom left of the IDE and visit our digital shop front, and keep an eye out for the free stuff!
Was so absorbed with the schedule, emails, tasks and delegation on Tuesday I completely forgot about blogging. I am here to rectify that a little and list out the stuff we have done in the last two days.
Changing the grass in Test Level is now instant, and no longer takes an absolute age. Added a MEDIUM technique to the entities to allow cheaper shadows along with the flash light effect. We extended the grass drawing range and made the grass fade out better so no more grass popping out of nowhere. The superflat terrain flag now handles the cheap shadow system properly allowing this method to be used for levels where terrain is not needed. It remains to be seen if we promote this feature to a slider/tickbox or keep it hidden in the SETUP.INI. The aspect ratio is now respected no matter what resolution you are running when in edit mode, which means perfectly circular cursors and scopes on rifles :) Fixed the issue of collectible weapons in standalone games not showing the guns when collected. The download system can now determine if an entity has been updated by the artist, and trigger the update to download automatically. Just log in each day, click download and if your purchased items have an improvement, they will be downloaded automatically. Added better interaction between water and entities so they bob about on the surface or sink to the bottom, no more jiggling about erratically. Added F10 reminder on the start-up prompt to show new users how to grab a screen shot from the Test Level session. The engine can automatically detect if an X file is NEWER than the DBO that represents it, and if so, replace it with a new one. This ensures the best performance via DBO and no further need to keep deleting DBO files after each update. Save standalone now remembers all settings in the root SETUP.INI allowing your executables to be exported just how you want them, no more manual editing each time. Skies, terrain and vegetation grasses lists now update each time you run Test Level which means you can buy a sky or grass choice, download it and then run the level immediately to try out your new item without needing to reset the software.
I also did half an hour looking into why the old DBP Free Version suddenly stopped allowing activation, which turned out to be a decent PHP version upgrade which messed up the security at our end. Paul came to the rescue and solved it in short order. New DBP users are happy once more!
Had a meeting today and refined the final list for the next version even further. We have isolated the most important features that the engine sorely needs and are working hard to get them working quickly. To give you a hint, it involves heavy coding of the AI, scripting, Windows 7/8 compatibility and a myriad of tiny yet essential tweaks to make the editing and playing of games enjoyable. Now we have a good upload system and a Game Creator Store administrator in place, expect to see items appear on the store in the coming weeks so don't be afraid to click the FPSCREATOR button in the bottom left of the IDE and visit our digital shop front, and keep an eye out for the free stuff!
Thursday, 17 April 2014
The Last Dev Day Before Easter
Work
The final day of development before the long awaited Easter holiday weekend (well not really long awaited, I only found out about it two days ago). Basically means the team will disperse for a few days after today so I am looking to spend less time on blitzing features and more time ensuring we have a solid build so when we return all the code makes sense.
Dave surprised me this morning with a rather funny video, and represents his first day working on new scripting commands:
https://www.youtube.com/watch?v=JaFiC4skVXM&feature=youtu.be
One issue experienced in the current beta is the slow 'top down editor' part which is using the HIGHEST shader settings. The latest one now migrates the shader settings, and I have just fixed the 'cheap shadow' system so it works in this editor too. Took a few hours, and I still need to increase the texture quality, but it works and any shadow will create a sense of depth which is useful for editing. The cool thing is that because I am now using LOWEST settings, the editor feels much faster, especially when lots of animations and things are placed down in close proximity.
Spent the rest of the battling with the combination of LOWEST settings in the editor, cheap shadows and SUPERFLATMODE=1 which produced a number of very irritating results. Ran out of time to find the cause, but have made a note and will resume the battle in the near future.
New internal build sent to Rick for testing, SVN cleaned up and the team wrapping up their respective offices. Been a good few weeks development and I am looking forward to a chill now, and even more cool development on my return. I will be sure to pop in from time to time on the forums however to see what's happening with the continuing saga of BETA 1.006.
The final day of development before the long awaited Easter holiday weekend (well not really long awaited, I only found out about it two days ago). Basically means the team will disperse for a few days after today so I am looking to spend less time on blitzing features and more time ensuring we have a solid build so when we return all the code makes sense.
Dave surprised me this morning with a rather funny video, and represents his first day working on new scripting commands:
https://www.youtube.com/watch?v=JaFiC4skVXM&feature=youtu.be
One issue experienced in the current beta is the slow 'top down editor' part which is using the HIGHEST shader settings. The latest one now migrates the shader settings, and I have just fixed the 'cheap shadow' system so it works in this editor too. Took a few hours, and I still need to increase the texture quality, but it works and any shadow will create a sense of depth which is useful for editing. The cool thing is that because I am now using LOWEST settings, the editor feels much faster, especially when lots of animations and things are placed down in close proximity.
Spent the rest of the battling with the combination of LOWEST settings in the editor, cheap shadows and SUPERFLATMODE=1 which produced a number of very irritating results. Ran out of time to find the cause, but have made a note and will resume the battle in the near future.
New internal build sent to Rick for testing, SVN cleaned up and the team wrapping up their respective offices. Been a good few weeks development and I am looking forward to a chill now, and even more cool development on my return. I will be sure to pop in from time to time on the forums however to see what's happening with the continuing saga of BETA 1.006.
Wednesday, 16 April 2014
Plenty V1 Tweaks Tweaked
Work
A good day today with plenty small fixes made which just polish the edges and make the software feel a little more compact and friendly. As this is a quick blog I will just reel off the stuff I did which includes a new superflat mode of 2 which will completely remove the terrain from the engine (entirely) so you can import your own ground or other floor surface. Added in some static floor entities and it worked a treat (and gave a monster speed up). Improved FPS Warning so it only strikes once the game loop is well established. Deleting zone entities in zoomed mode no longer leaves area zone marker in map. FPSCR will now only accept and load levels created exclusively in Reloaded, and will produce a warning for Classic FPM files. Flash light now works for LOWEST and MEDIUM shader techniques, and I have added a new MEDIUM shader technique for entities to allow a cheap flash light and a real flash light effect to be chosen. Amazingly, FALLOUT3 only used a proximity flash light rather than conical one! Ambient settings no longer lost when loading, saving and creating new terrains. When setting low shader techniques in test game, this choice is carried back to the editor so you can have faster editing experience (though it does not look as good from high up).
On top of this, usual forum checking and delegating and testing tasks for Dave and Simon which are making good progress in their own right. Dave just fixed the download system so it now uses a cool check-sum feature to ensure the download is 100% successful and also allows us to detect when an entity has been modified by the original artist and the software automatically updates it for you. Simon has solved the floating grass issues and made some performance improvements which he was in there :)
Thursday is the last official work day in the UK, so our combined plan is to crack on with our list of super-A critical items and giving us enough time to check in and test what we have before the Easter break. We've all worked like crazy people these last weeks and the break will do everyone some good, recharge those batteries and come back stronger (at which point we have to remember what exactly it was we we're coding) ;)
A good day today with plenty small fixes made which just polish the edges and make the software feel a little more compact and friendly. As this is a quick blog I will just reel off the stuff I did which includes a new superflat mode of 2 which will completely remove the terrain from the engine (entirely) so you can import your own ground or other floor surface. Added in some static floor entities and it worked a treat (and gave a monster speed up). Improved FPS Warning so it only strikes once the game loop is well established. Deleting zone entities in zoomed mode no longer leaves area zone marker in map. FPSCR will now only accept and load levels created exclusively in Reloaded, and will produce a warning for Classic FPM files. Flash light now works for LOWEST and MEDIUM shader techniques, and I have added a new MEDIUM shader technique for entities to allow a cheap flash light and a real flash light effect to be chosen. Amazingly, FALLOUT3 only used a proximity flash light rather than conical one! Ambient settings no longer lost when loading, saving and creating new terrains. When setting low shader techniques in test game, this choice is carried back to the editor so you can have faster editing experience (though it does not look as good from high up).
On top of this, usual forum checking and delegating and testing tasks for Dave and Simon which are making good progress in their own right. Dave just fixed the download system so it now uses a cool check-sum feature to ensure the download is 100% successful and also allows us to detect when an entity has been modified by the original artist and the software automatically updates it for you. Simon has solved the floating grass issues and made some performance improvements which he was in there :)
Thursday is the last official work day in the UK, so our combined plan is to crack on with our list of super-A critical items and giving us enough time to check in and test what we have before the Easter break. We've all worked like crazy people these last weeks and the break will do everyone some good, recharge those batteries and come back stronger (at which point we have to remember what exactly it was we we're coding) ;)
Tuesday, 15 April 2014
BETA Launch Day
Work
After many weeks tweaking and testing, we released the new 1.006 beta onto the unsuspecting public, and the feedback so far is very good. We did a good job testing for stability and the performance improvements are experienced by almost everyone. Those still on HIGHEST settings will see the smallest benefit as we focused on LOWEST for the lower end systems.
Here is a shot of something I was messing with, getting the sky, fog and land color tint to match to create a different feel and style even though it's just plane old LUSH style.
I was planning dive straight into the remaining features of the software, but it was brought to my attention that a better strategy was to stick around the forums and assist in the early feedback of the BETA and help out where I can. I have decided this is a good policy and will continue this until Thursday PM. Friday through Monday is a bank holiday here in the UK, which means my team downs tools and runs for the hills for a much needed recharge. I also plan to see a few castles over the brief holiday, but will be back every evening to play FALLOUT3 and a few other games I have to catch up with, and of course checking into the forums and maybe doing some more tweaks.
All in all, the teams dedication to focusing on core issues and then PLENTY of testing has produced a solid version which I am happy to release today, and if we spend the next six weeks with the same laser sharp attitude to completing this product in a timely fashion, we'll be in a great place to then add all the cool features you have been voting for on the Vote Board. Once again thanks to all our pledgers for making this software possible, and we hope you've enjoyed the journey so far.
After many weeks tweaking and testing, we released the new 1.006 beta onto the unsuspecting public, and the feedback so far is very good. We did a good job testing for stability and the performance improvements are experienced by almost everyone. Those still on HIGHEST settings will see the smallest benefit as we focused on LOWEST for the lower end systems.
Here is a shot of something I was messing with, getting the sky, fog and land color tint to match to create a different feel and style even though it's just plane old LUSH style.
I was planning dive straight into the remaining features of the software, but it was brought to my attention that a better strategy was to stick around the forums and assist in the early feedback of the BETA and help out where I can. I have decided this is a good policy and will continue this until Thursday PM. Friday through Monday is a bank holiday here in the UK, which means my team downs tools and runs for the hills for a much needed recharge. I also plan to see a few castles over the brief holiday, but will be back every evening to play FALLOUT3 and a few other games I have to catch up with, and of course checking into the forums and maybe doing some more tweaks.
All in all, the teams dedication to focusing on core issues and then PLENTY of testing has produced a solid version which I am happy to release today, and if we spend the next six weeks with the same laser sharp attitude to completing this product in a timely fashion, we'll be in a great place to then add all the cool features you have been voting for on the Vote Board. Once again thanks to all our pledgers for making this software possible, and we hope you've enjoyed the journey so far.
Monday, 14 April 2014
Almost Last Day Of Testing
Work
I get the impression that the version we are testing is also the version the 'everyone else' will be getting and I must say it's holding up to tests. Over 50 sequential clicks at Test Game button without crashing, no memory issues, faster performance across the board, many small tweak conveniently squashed, and who know what other small benefits. I think our trio did quite well this last few weeks, and a good formula for the future.
I 'could' list all the small tweaks, but as half of them where fixes for things that formerly worked, it's not going to make much sense as an isolated list. I can report general improvements across the board, and certainly some improvements in performance when you set the shaders to LOWEST.
I am most pleased with the stability and memory activity of the software however, which allows extremely prolonged sessions without worrying about memory fragmentation. Of course, plenty of more opportunities for optimization but as far as final builds go, I think this one is pretty special. The internal and core teams will be testing this for some of Tuesday AM and with a little luck we can release to the whole pledged world very soon after that. Wish I could provide some nice screenshots for you, but truth be told, the community are producing some awesome shots already I dare not attempt to challenge their authority in this matter.
Beyond the beta release, we make our plans to improve the next 'most needed' feature which is scripting and AI. We have a little of both right now, but we want to inject super-powers into both systems and get the game play as stellar as possible for FPSC Reloaded. In additional to the myriad of minor tweaks and fixes, our big feature for the next release will be A.I so place your characters in your levels now in anticipation of the hideously smart intelligence we will bestow on them in the next major release.
The whole team are pretty buzzed with the current beta and we hope you enjoy it too. If you have any comments on the version, you know where to post it. Until the next blog post, enjoy!
I get the impression that the version we are testing is also the version the 'everyone else' will be getting and I must say it's holding up to tests. Over 50 sequential clicks at Test Game button without crashing, no memory issues, faster performance across the board, many small tweak conveniently squashed, and who know what other small benefits. I think our trio did quite well this last few weeks, and a good formula for the future.
I 'could' list all the small tweaks, but as half of them where fixes for things that formerly worked, it's not going to make much sense as an isolated list. I can report general improvements across the board, and certainly some improvements in performance when you set the shaders to LOWEST.
I am most pleased with the stability and memory activity of the software however, which allows extremely prolonged sessions without worrying about memory fragmentation. Of course, plenty of more opportunities for optimization but as far as final builds go, I think this one is pretty special. The internal and core teams will be testing this for some of Tuesday AM and with a little luck we can release to the whole pledged world very soon after that. Wish I could provide some nice screenshots for you, but truth be told, the community are producing some awesome shots already I dare not attempt to challenge their authority in this matter.
Beyond the beta release, we make our plans to improve the next 'most needed' feature which is scripting and AI. We have a little of both right now, but we want to inject super-powers into both systems and get the game play as stellar as possible for FPSC Reloaded. In additional to the myriad of minor tweaks and fixes, our big feature for the next release will be A.I so place your characters in your levels now in anticipation of the hideously smart intelligence we will bestow on them in the next major release.
The whole team are pretty buzzed with the current beta and we hope you enjoy it too. If you have any comments on the version, you know where to post it. Until the next blog post, enjoy!
Friday, 11 April 2014
Thank Almighty Bob It's Friday
Work
Another good day, filled with a notable success. Not only have more fine tweaks gone in, but the best news of the day is that we managed to locate and plug a 40MB leak, which happened each time you click TEST GAME. It basically means your editing sessions got substantially longer!
As the monsters lurking inside the engine begin to get thinned out, we start to catch a glimpse of the game creator we all want. I am now assigning the whole team the challenge of locating and eradicating any remaining memory leaks over a double of Kb. Anything smaller will not harm you, but we will eventually get to them all, so we are focusing on the ones that cause your system memory to run out.
The internal plan is to release something next week, but this is not confirmed and it all depends on the results of the larger internal test we are conducting on the new version. We realize you have been very patient, and so we want to give you something worthwhile (and hopefully worth the wait).
My trilogy of coders are getting 'very' familiar with the whole engine, from the IDE, the DBP code through to the C++ modules that make it fast. We're almost at the point where anyone can jump in and code any part, which makes for a devastating core team on Reloaded. I am personally looking forward to the post BETA development when we get to have fun with LUA and AI, but focus will remain on this version and the mission is to ensure it's a solid and reliable version you can continue to create your levels with while we work on the logic side of things for you.
Another good day, filled with a notable success. Not only have more fine tweaks gone in, but the best news of the day is that we managed to locate and plug a 40MB leak, which happened each time you click TEST GAME. It basically means your editing sessions got substantially longer!
As the monsters lurking inside the engine begin to get thinned out, we start to catch a glimpse of the game creator we all want. I am now assigning the whole team the challenge of locating and eradicating any remaining memory leaks over a double of Kb. Anything smaller will not harm you, but we will eventually get to them all, so we are focusing on the ones that cause your system memory to run out.
The internal plan is to release something next week, but this is not confirmed and it all depends on the results of the larger internal test we are conducting on the new version. We realize you have been very patient, and so we want to give you something worthwhile (and hopefully worth the wait).
My trilogy of coders are getting 'very' familiar with the whole engine, from the IDE, the DBP code through to the C++ modules that make it fast. We're almost at the point where anyone can jump in and code any part, which makes for a devastating core team on Reloaded. I am personally looking forward to the post BETA development when we get to have fun with LUA and AI, but focus will remain on this version and the mission is to ensure it's a solid and reliable version you can continue to create your levels with while we work on the logic side of things for you.
Thursday, 10 April 2014
Thursday Triumphs
Work
Another good day so far of testing and tweaking, mostly playing detective with some rogue memory leaks. The biggest and best news from me is that I managed to reduce the start-up system memory usage by 190MB bringing it down to just 430MB with full terrain system. We also made some good strides on the store and also some key crash fixes which we found during extensive testing. Cannot do a big blog as I need to get right back in it. I am currently stepping through the test game in/out process to find out why it can leak anything from 500Kb to 65MB after a single test game session. This work has already yielded a fix which prevents anything greater than 4MB from being allocated during the test game set-up (at least the DIM stuff), and is just a case of tracking as much of this stuff as possible in the time remaining. All in all, progress goes well!
Another good day so far of testing and tweaking, mostly playing detective with some rogue memory leaks. The biggest and best news from me is that I managed to reduce the start-up system memory usage by 190MB bringing it down to just 430MB with full terrain system. We also made some good strides on the store and also some key crash fixes which we found during extensive testing. Cannot do a big blog as I need to get right back in it. I am currently stepping through the test game in/out process to find out why it can leak anything from 500Kb to 65MB after a single test game session. This work has already yielded a fix which prevents anything greater than 4MB from being allocated during the test game set-up (at least the DIM stuff), and is just a case of tracking as much of this stuff as possible in the time remaining. All in all, progress goes well!
Wednesday, 9 April 2014
Wednesday Test and Tweak Day
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.
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.
Tuesday, 8 April 2014
Sat Down For 2, Stayed for 5
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...
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...
Monday, 7 April 2014
timeGetTime Revealed
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).
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).
Friday, 4 April 2014
Presenting Present
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 :)
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 :)
Thursday, 3 April 2014
New Debug Features in Reloaded Core
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 :)
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 :)
Wednesday, 2 April 2014
Internal Testing Heat
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!
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!
Tuesday, 1 April 2014
More Stutter Work
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!
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!
Subscribe to:
Posts (Atom)