Actually, I have just started this blog and the day, and have no idea if today will turn into a Reloaded marathon, but this is my intent. I had planned to start the player control system but having used the editor to do some fun play testing, I realised there are some loose ends that need finishing off. The blueprint graphic from the old system shows through from time to time which is not helpful, the was I slice the visuals so you can see the layer you are editing chops off cursors and the level does not light completely when you load a new map.
This is enough to make the whole thing feel unfinished, and I think it makes sense to tie these off now while I am closest to the time I messed it up. Even though control systems and physics is exciting and cool to work on, the sensible course is to make the current editor as close to final as is practicable.
You might be wandering why I am not outside enjoying the sun shine? Well, the weather man said heat wave, and right on schedule, the exact opposite blessed my Sunday with rain and clouds. So no repeat BBQ and no outside wheel barrow (or barrel) work. I consider myself quite smug now that I snook off and enjoyed the sun while it was available, and will probably make it a policy to do so this summer so I don't miss any 'good days'.
2PM : Playtesting
As is my ritual, I spend 10 minutes just playing with the current state of the software to get a feel for what is blatantly bad. It is obvious the editing process has been disrupted a little and I need to 'put it right' so it feels as solid and visually crisp as ever. I have made a small list for my reference, and intend to work through it as the day unfolds.
3PM : Loading In
The old system would load the map and then 'maybe' use the last loaded light to illuminate the scene. Not ideal as the scene could be full of details that need lighting. I have added a system to create a cascade of light map updates for each light in the scene just after the level loads in, so the user only has to wait and watch as the lighting is restored. I am not going the other route of saving the light maps with each FPM file as I like the fact they are very small and interchangeable.
It's a minor thing, but when you load your level you want to see it in the proper light (pardon the pun and the classic graphics).
3:35PM : Object Cascading
Similar to above, when you draw lots of segments very fast, the light mapper can skips objects during the light mapping and so they appear unlit in the scene, which looks bad. I am adding a system which will store all objects in a list, and then use that list to feed the light mapper. This will create a trail which the real time light mapper can follow to ensure ALL objects are light mapped as you are editing.
3:45PM : Very Nice
The object cascade system works very nice, it actually ran backwards with the newest object being light mapped before the older ones, but I like this as it maintains focus on what the user is doing right now and not older stuff that might be far away from the scene of editing. I think I will keep this order. I also noticed the cursor is flickering all over the place so I will see if I can tame that and also sort out the visibility of the cube cursor (such as those used when editing segments) so they once again appear whole and unclipped so I can see the top of them. Right now my layer slicing system is cutting their tops off!
4:10PM : Performance Boost
The first implementation of the object cascade light mapper seemed to be light mapping objects around the newly added object which was not ideal as complex areas would trigger a lengthy light map step multiplied by all the objects in the area, lightmapping objects that had already been lit. By adding some extra code which removed objects from the active cascade list when they where indirectly lit by a previous lighting step, all redundant light map requests are eliminated and a faster lighting experience ensues. Hurray!
4:28PM : Not Entirely Happy
There are cases where segments which have already been light mapped in previous passes are being included in the cascade list, but there is no 'memory' to tell me these objects should not be included so take up precious time. It's not critical, but as an observer, you might be left wondering why the light mapper is going ten to the dozen without any light map changes taking place. Maybe I will come back to this if it becomes intolerable. On top of that, my latest monster test just crashed without giving me a call stack trace which is not very helpful. Will start running in debug mode in case it happens again.
4:40PM : Polish Early
I noticed when there was a quick light map step such as one segment tile the light map status bar flickered as it went from zero to one hundred in a few milliseconds. Not pretty. I have added some smoothing code which increases the alpha of the status graphic the longer it's being used, so a quick step should not show and a longer process will show the bar fading in and then fading out. Not easy either as it's very much a case of looking at the activity of the light map percentage value and working out when to bring up the alpha an when to hide the status bar altogether. Still, should be worth it when done correctly.
5:10PM : A Spot Of Lunch
I've just finished the above polished light map status bar and also removed the camera range slicer which messed up so much. After lunch I am going to see if I can go back to the idea of hiding layers of no interest during the edit process. Ideally I only need to traverse the 'massive' object group when changing layers so theoretically should be a good solution. Time and experimentation will tell...but first, food.
5:40PM : Soupee-Twist
Just finished my spot of lunch and finished watching half an hour of great comedy on Netflix. Congratulations if you can figure out what it was. Just ran Reloaded to see where I was, and the clip slicing as gone which means I need to replace it with something else. That will be my mission now..
6:00PM : Mission Aborted
The object cascade list system is not ideal. A simple segment room with two storeys and a single light seems to have a lot of objects to repeatedly light which is nuts! I think I will return to it and 'dump' the whole object list into the light mapping pass so it gets it over with in one go. It might mean less frequent light map updates, but it will eliminate the current system issue which seems to want to process objects fully 60 seconds after the last light map change was detected. Grr.
6:15PM : Label Text Moved To Status Bar
When I adjusted the size of the back-buffer for perfect 1:1 pixel quality in the test game mode, the map editors smaller window scrunched up the text. The two back buffer sizes cannot be reconciled and naturally we prefer the higher quality test game render, so I have moved ALL text from the map editor over to the status bar in the IDE. It means the editor is less cluttered and the text is also 1:1 perfect too so another win-win.
7:25PM : Three In One
In moving to the next bit which was hiding non-current layers, I realised the alpha mapping code was not working. Rather than mess about with fixed function questions, I realised that the editor will be using shaders directly in the final product so decided to skip to adding a basic universal shader to the map editor so the alpha factor functionality would once again work. It also means we're one step closer to the final editor visuals which will feature the full shader rendering, not a washed out representation as in the old engine.
8:35PM : Shaders Are Buggers
I always have a fun old time with shaders, that is, they are a royal pain in the butt sometimes. Most of the time they have errors, and just disappear, but you don't know whether they are invisible because of the shader, or invisible because they are working with alpha at zero. Grr. And don't get me started on the task of integrating the shader with the fixed functionality of the light mapped object after the real time light mapper has finished with it. So much to do that's so obvious, but so far away...
10:28M : Making Slow But Steady Progress
I have the layers separated by layer now based on the layer you are editing using the new alpha mapper on the freshly made universal shader. The new shader is based on one of Mark Blosser's creations and works out the box so I can adapt as I go. My first adoption was to allow the alpha to be overridden so the editor could fade out individual objects.
I re-introduced the light mapper and of course, boom, all alpha stuff ignored. Now I need to make sure the real time light mapper can handle shaded objects as I don't fancy making the code re-apply the shader after light mapping as it seems redundant when the back-end could do it quicker and more elegantly. That is my next port of call. I think I made the right call sorting these varied issues out and not jumping into cool physics and control systems, it's the boring stuff that really needs pinning down to ensure it's a great user experience at the edit end of the product.
Well it's a few minutes to midnight and I've not eaten since my spot of lunch, and right now when I drop in a large segment my lovely light mapper crashes. I probably should not have starting blending the shader and light mapper into one thing as it's a big thought to do and it was the back end of the day. Just going to stop it crashing by backtracking a little, then calling it a night. Can't abide leaving a project with a crash at the very front of it. Once I've tackled that, a spot of 'midnight dinner' and then off to beddy bye boes.