Wednesday, 10 April 2013

Wednesday Locked And Loaded

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!


  1. My current DBP project is 29k lines, and takes 3:52 to compile. If you manage to make a faster compiler, please release it to the DBP community!

    And I enjoyed your videos, and could see past the placeholder art. I use it myself. People can be too harsh at times...

  2. "My current DBP project is 29k lines, and takes 3:52 to compile. If you manage to make a faster compiler, please release it to the DBP community!"

    Definitely! I've never had any DBPro program that's 29,000 lines long (!!), but I've had ones that are fairly long (3000+) and any speed improvement would be much appreciated :) I just downloaded the latest FPSC DBA from the SVN and my custom line counter reports 57,451 actual code lines (not blank lines or commented lines)!

    I also enjoyed the videos thoroughly and they even made me excited that you (Lee) really do understand what needs to be done in FPSC-R; when FPSC-R was first announced I was completely convinced that you would simply re-write some shaders so that everything was shiny (which is usually unrealistic). I can't understand how anyone would see the placeholder art as anyone other than placeholder art. You've really got to wonder, sometimes...

    Anyway that proximity mine looks seriously cool! Good work, Mr. Blosser! The only thing is, it looks like a land mine rather than a proximity mine, but that's not a problem since we can easily make it into a land mine with a simple script :D I can't wait for FPSC-R!

  3. I really love watching work-in-progress videos, programmer art and all. It can also be a great way to build up interest as it is easy for people to follow its progress (I remember when Notch first started posting WIP videos of Minecraft long before anything was released). I also remember seeing early concept work for Braid with terrible placeholder artwork, and being blown away by the final product after a graphic overhaul. I think many game development companies, small and large, post conceptual artwork and WIP previews without any trouble as it's obvious it is not in final form.

  4. You will have to convince Rick at of this perspective. Right now he thinks all coders (well, me) should be banned from producing art and everything created should instantly look finished ;) Don't worry I am sure there will be something show-worthy soon enough!

  5. To reduce compiling time, add raid'ed SSD disks, on a system with the fastest 6 core intel processor. You can always test your compiled code on the old computer your using now. One should never run a project on the computer your programming it on... suddenly the program crash and corrupt the whole system...