All ideas expressed in this blog are temporal and any resemblance to manifested reality are purely co-incidental. The forgoing is a casual musing from a fellow coder, not an iron clad promise of features and products - The Law
Late Last Night Whilst dozing in front of a few episodes of Wheeler Dealer I got an email, and boy what an email. Mark has finished his first draft of the Reloaded character model and it's stunning.
If you don't believe me, check out the close-up of the face and especially the eyes. Now imagine when this guy is talking, and you'll get some idea of the level of quality Reloaded will inflict on you!
I am super excited to see this, and can't wait to start a new prototype that will have him put through his paces. Behaviour and AI will be a big feature of the new FPSC Reloaded product and the character will be the vehicle by which we will demonstrate this feature. Happy Days! On The Coding Front As I reported over the weekend I increased the speed at which I can compile the FPSC engine which means it is almost four times quicker for me to change something then see the results running. A breath of fresh air so far, and it really feels like the development has become more fluid. No more surfing the net every compile which I wait for it! I'm working on the entity creation and placement now, and also the entity floater object which is the entity attached to your cursor just before you place them down. With these in place, and added to the segment stuff which is done, I will have rewritten the whole real object shroud system of the old FPSC forever and from here on in, all objects are created and retained. A nice bonus to this new system is that all textures and shaders are applied to full objects, not instances, which means when you customise an entity, you will see that customisation in the editor right away. In the old FPSC engine you had to wait until you played the game before you saw any changes you made to the entity texture or shader.
Signing Off It's about 2PM now, so time for some beans and toast, then onto finishing the entity stuff, and a big stress test on what I have so far before moving much further. It is vital I ensure there are no leaks, no loss in functionality and that what I have done will stand up well for the rest of the project. It's the best time to do stuff like this as the code is still fresh in my mind. Once we wave good bye to these tasks, the next fun task is Collision and tackling the dreaded 'fall through floor or get stuck' issues of the old universe.
Surprise Blog I know I don't normally blog the weekend (otherwise the ritual would paint my addled brain into a corner from whence escape would be impossible), but the momentum of doing the Perceptual Computing Challenge has given me a sense that weekends are okay for extra coding. The day light was spent shovelling shale from one side of my garden to the other, and the evening was spent watching the Magicians with David Mitchell and Robert Webb (very funny guys). A bit of inspiring end credits music got me thinking that maybe I could throw a few hours at Reloaded, and so I did. My Few Thrown Hours It occurred to me at the end of a full week of Reloaded development that one of the biggest obstacles to quick progress was the speed of the DBP compiler (currently 3 minutes on my monster Reloaded PC). I figured if I could have a faster compiler, I could do more compiles in the day and the thing I was tweaking or fixing or adding would be fresher in my mind and next week will produce even more Reloaded goodness. Secret Super Coder After ten plus years running a software company, you cannot help but perfect the art of delegation, and sometimes it pays dividends. One such delegation brokered the assistance of a top coder, who kindly volunteered his time to help me spruce up the internal version of DBP, starting with the compiler, in anticipation of larger DBP projects such as Reloaded. The fantastic news is that an early version of the new compiler has taken my compile time from 3 minutes down to 45 seconds, which is an immense speed boost when you are typically compiling about 100 times a day minimum. My few hours this weekend in integrating this new version with the Reloaded dev set-up will save me literally days of time over the course of the remainder of this project! Those acquired days can be fed back into the engine to make it even better and make my coding life sane once again. Before every DBP coder starts jumping up and down, the compiler is far from finished and the 'super secret top coder' will want paying for his efforts too, so it will not be a free update. My priority remains Reloaded all the way through to October, and all forces will be steadily employed in this direction, but along the way if the opportunity exists to commercialise these internal DBP enhancements, you will be the first to know! A Note On Concurrency The term 'concurrency' is often used to describe how many cores your app is using at the same time (i.e. running concurrently side by side). For fun I draw a few rooms and dropped a light into the map editor of the current Reloaded product. I then opened the performance profiler which indicates what my four cores where doing. Guess what. Processor utilisation was 100% from the moment the light was placed through to when the light mapping appeared. That means all four cores where red hot to get the light mapping done as quickly as possible on the monster machine it finds itself on. Intel would be very proud of an app like Reloaded, and for the first time FPSC will be tapping every corner of your processing power even as you edit and tweak your levels.
I also plan to get the same (or near) when you play the game too, thanks to the multi-core DarkAI system which will be asked to calculate some fiendish math to figure out the best way to strike at the player. Getting full concurrency when you edit and when you play will mean we have a piece of software that pushes your machine to the maximum. Signing Off It's now 2:30AM and I will be turning in very soon. I'm happy with this coding stint, not least because it has just improved my life by 2 minutes 15 seconds per compile and once I have stripped out the old 'build process' and 'blue print shroud system', the code base will be even smaller which means even faster compiles. That is, until I add the new bullet physics system, terrain system and combat intelligence systems the likes of which you'll have nightmares about. A big player in the internal Reloaded team suggested this product needs a killer feature to make it stand out from the crowd. Rick, our resident pessimist[realist], concluded there are no killer ideas left, and everything has been done, and small teams like us don't have the manpower for that level of innovation. I disagree. I think it is precisely because we are small that we can take a risk on a killer idea that might very well transform the FPS genre forever. I don't know what the idea is of course, and I dare say it may never surface, but if you have an awesome idea you've never seen in an FPS, post your comments here, I read them all!
Getting Real It is great to be away from a prototype and into the main engine. It has been some time since I really got my hands dirty inside the FPSC source code and it is all coming back to me, and really how complex the whole process of building the map actually is. Lots of considerations that seam completely natural at the front-end need plenty of code to make it a smooth editing process. Of course there are some bits of code that are quite shocking, and are scheduled to be removed and rewritten at some point. Current Progress I managed to get segment painting working with adding multiple lights this morning, which was great to see, and even fixed a texture issue which means you can light map the same object over and over. I was going to make a screen shot for you, but then decided the current code was obsolete as it assumed the objects needed recreating each time something was added. The old system did this using instance objects, but the new system does not require this traversal. Simply adding and removing the object at the point of the event is sufficient, but it meant removing a chunk of legacy code, and as I write this I dun broke it. No worries though, it has to get worse before it gets better. The new system will mean that as I increase the map size to 200x200x20, the engine does not have to traverse every single map reference to check if a grid tile has been changed (which would have been the case had I kept the old system). The new one will create the object on demand. Right now it is perhaps creating it, but bot showing it in the right place. Going well though! Signing Off My hope for the end of Friday is to be able to draw a simple Alley scene comprising segments and static entities, then drop in a few lights and watch as they auto light map. Then to be able to remove both segments and entities and when I add a new light the scene amends itself. I am not aiming to get light mapping to trigger on segment and entity removal just yet, as I want to make sure the "add/remove light" trigger works 100%. Currently having a ball, and it's nice to see FPSC take a few tentative steps into the future :)
AM to PM Another long Reloaded day, with almost all of it within the FPSC source code :) I was distracted for no more than 20 minutes on a quick AGK fix, but right back into the light mapping work! Success.
Current Light Mapper I have moved from the prototype to the main engine now, and redesigned the way in which the segments and entities are painted in the editor. Not outwardly, but internally the objects are no longer instances but clones so they can be light mapped, and with this I was able to paint down a few floors, drop in a light and presto, an almost instant light mapped ring of light. After a little more work I could add several lights in, and again the light map would automatically adjust and the scene would be pre-lit within seconds. As expected, now came the army of small unpredictable gremlins to spoil the party. When you click New to create a new scene, the old objects had to be deleted, and of course light mapping is still occurring so of course the whole thing crashed when I tried to reset the level. I also cannot delete any segments right now as the new system only handles additions to the scene, and of course when I start deleting these objects I will have the same issue as above with the light mapper not quite ready to let the object go. This might not be a problem if the light map process is a few seconds, but a complex scene can take 10-20 seconds to light, and does the user want to wait that long before they can load a new level or start again, no.
Signing Off My task for the remaining few hours and perhaps this evening is to bring these crashes to heal by adding a new light mapper command which can extract an object immediately from the scope and responsibility of the process, so one or all objects can be removed and the light map process terminated gracefully. It's also not straight forward as when using threads (which the real time light mapper certainly does), a crash is often reported in a different location with no call stack to fall back on, so it's pretty much a case of trial and error tweaks until the true cause of these drop-outs becomes apparent. Hopefully tomorrow I can bring news of victory over these gremlins.
And Their Off Taking my own advice, and that of others, as soon as I logged onto my PC this morning I deliberately avoided checking emails and instead booted the Reloaded PC and started from where I left off. Where I Left Off The last thing I did before writing Tuesday's blog was identify where the prototype was crashing, the result of textures being released even though they where still being used by other objects. The trick with lightmaps is that one texture can be shared by hundreds of objects, and not all the objects will be updated with the real time light map each frame. This means you have new light map textures and old not yet affected textures side by side. You cannot just delete a light map texture because ONE object started using a new texture. The solution which I implemented last night was to create a reference count list of all textures assigned to objects, and then decrease that count when the texture was no longer used by an object. Only when the count reached zero did I now that NO-ONE was using the ageing light map texture and I could remove it. This worked well, and further work ensured there where no leaks and the process could be left running with only minimal fragmentation in memory. This Mornings Work The next task was to allow entity creations, movements and deletions to affect the infinilights structure which controls what lights are recorded in the game scene. This structure was not used previously in the map editor part so had to be moved across and made to play nice. I also added some code which prevented the light mapper from saving out the light map files as we only really need the texture to exist in memory at this stage. The files are only needed during a final standalone export, so removing this saved precious performance. The final step was to extract the code from the prototype that was to be used in the engine and create a separate code file for it (FPSC-M-RTLightmap.dba) and move the new data structures required by this new feature to the types code file. With this complete, and the prototype still working nicely, it was time to switch over the monster code file, the FPSC engine itself! The Monster FPSC Engine After integrating the new code file and inserting four subroutine calls into the map editor part of the code, I compiled, ran and got my first (of many) crashes. Back into the RTLM code file, made a tweak, ran again and no more crash. Added my first light entity, crash. This is where you find me now at 2:30PM. I do have a few hours I need to put into the email and some last minute Android AGK bits, but from now on I think this formulae will work out just fine. FPSC Compile Speed Let's face it, three minutes per compile is atrocious, and it will severely hinder the speed at which I integrate the various parts of the engine and of course that all important final testing and tweaking. I have made steps to improve this in the DBP compiler but cannot reveal more at this stage, but I am confident that I will be able to reduce the compile time significantly in the weeks to come. My priority though is to finish the light mapper with the present compiler so I can reach a milestone that should have been finished over a month ago. Grr.
Lovely New Art I am sure Rick will not mind me sharing videos that are representations of final artwork, so I have uploaded the Proximity Mine that Mark has kindly created for the project:
It's a proximity mine which you can magnetically place on any surface, and will detonate when anyone gets too close. Combined with the new explosion and in the future augmented with a physics blast that will make you think twice about venturing closer, we're going to have a blast with this new toy!
Signing Off The extreme compile times of FPSC allow me much spare time to write my blogs so I will probably be writing them in the Morning/Mid-Day as I code Reloaded, and it also means the stuff is being reported while it is fresh in my mind. It's been really great waking up and spending my best most sharpened hours on Reloaded, reminds me of the olden days!
Death By A Thousand Cuts After a brief phone call with Rick today, I realised that 24 hours, a plate of beans and a round of toast was enough to completely side track my brain into replaying the old mind set of answering emails, dealing with little bits of jobs here and there, and not actually spending a great deal of time on Reloaded. Yes, all the tasks where important to some degree, but they seemed to automatically get placed on a high priority for the simple fact they cluttered my inbox. Back in the day, we did not have in-boxes or emails for that matter, and a lot of ruthless development got done. Some Ruthless Development As of today, I am going to play a game I like to call 'Ruthless Reloaded Development' and see how it pans out. Many worthy causes will be sacrificed this week, but it's an experiment I am curious to see the outcome from. First quick job is to finish the memory management of displaced texture memory from the real time light mapper and get it leak free. From there, I can drop it into the main engine and see what it looks like for performance and visuals. In other camps, Mark is fired up to produce a proximity mine for our latest munition prototype, and also to begin creation of the new character template for Reloaded which I intend to be very awesome indeed. I might be showing videos for a while, but I think I can show you the cool artwork as it comes in. We also have our 2D artist producing mock-ups for the new IDE and map editor visuals as well, so hopefully I can show you the various themes we will be choosing from. The idea is to give FPSC a totally new modern look and of course resolve those little interface niggles we have come to know and love. A Day Of Two Halves As I woke up at noon today, I have promised myself a few more hours this evening to make up for my lie-in. If I have not cracked the real time light mapping memory leak and added it into the main engine I will be most vexed. I will be able to report my progress on Wednesday's blog and let you know how it went. Signing Off For the rest of this week my email inbox will be playing second fiddle to booting up the Reloaded PC and getting stuck in, so I apologise in advance if anyone is waiting around for a reply. Consider me cave-bound!
A Happy Place After the intensity of juggling several projects and a super intense competition (and no weekends or sleep), it's great to finally be able to sit back and have only one project in front of me, and what better project than FPSC Reloaded! I had a strategy meeting today to discuss overall plans and directions, and you will be pleased to hear that we are putting more eggs into the Reloaded basket and making sure it really delivers when the time comes.
Magnetic Mines A new version of the magnetic proximity mines came in today which was great to see. You are still throwing them like grenades, but the mechanism is now there to throw, place, drop, hoist them where ever you please. Mark will be working on a nice graphic so we can see them pulse dangerously and should make a great addition to your arsenal. Due to recent comments from various social feeds, I have now been banned from showing early video footage of Reloaded prototypes. The decision has been made to only show videos that contain final or near final artwork which reflects what you will get in the finished product. You will still get rants from me, and pictures, but video production and release has been handed to Rick so he can control the quality here. I often commit the sin of thinking everyone looking at the videos can see past the obviously ancient art and imagine what it could be like, but of course the world does not work that way. Signing Off Meeting days always sap my energy so this will be a shorter blog (and day). I also worked to 4AM Sunday to finish my final UCCII blog post and video. I have done all I can bar some final external testing and tweaks to the installer and I hope the app behaves itself in front of the judges. Here is a taster of what the final blog had in store for it's readers. Often is the case the coolest stuff happens in the last five minutes, and the PerceptuCam app is no exception:
The above idea is the first stab at creating an instant visual cue from the gesture data before allowing the user to summon commands with the wave of a wand. It turns out that even though wands are fictitious story elements, they also make surprisingly good ways to produce accurate gestures! It has also not escaped my thinking that once Reloaded V1 is out the door, adding gesture control to the create and play elements of FPSC is not such a bad idea. Until next time, have a good evening!
