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