Tuesday 28 May 2013

Monday and Tuesday Backloggin

Backlog Mountain

As I had a long weekend, thanks in part to a UK bank holiday and birthday party, the PC was not touched for the best part of three days and as such, plenty of emails and letters to wade through on my return.

I have a few short days to squeeze some coding into, and then I am off Jet-setting again to meet our mysterious Reloaded investor who is in London for a few days.  All my travel arrangements are booked, printed out and my car is due for a quick service Wednesday to ensure everything goes smoothly.  I am really looking forward to the meeting, and as I am in London, also looking forward to finding a nice Irish pub dispensing the very best Guinness.

So even though your friendly neighbourhood Lee has been barely active, the Reloaded universe continues to turn with the small team growing around the project.

Tracers Ahoy

The tracer prototype is coming along nicely, with blazing streaks of heat whizzing past the players head and scorching the air. The final visuals from mark and the sound contributions in the module really came together and I am excited to add it to the engine when the time comes.  The system is also pretty configurable from the gunspec file as well, so modders out there with ambitions to create new Reloaded weaponry will have a great time!


Firstly sorry for the classic art (not representative of Reloaded art), and secondly, check out the white line at the bottom of the screen. This is a tracer that fires from the barrel of specific guns to give you some idea how close that enemy bullet was. The scene will get pretty lively during the action, and tracers will be a valuable element of that visual splendour.

Character Accent 

Another wonderful surprise from the art lab as we get to see more of the versatility of our principal enemy protagonist. Here we see him climb a two segment high ladder, complete with commentary from the man himself:


Of course I am itching at the bit to get stuck in and add this to the engine, but I have to practise patience.  I have a level engine to put back together, a lighting model to decide on and some basic physics and occlusion so we can run around a typical level and see some normality again.

Signing Off

My brain was not entirely idle over the weekend and it did turn once or twice to the request made on one of the comment boards that the level size should be 500x50x500 rather than 20 units high.  While it is true such a dimension would not be exploited by the masses, it suggests that at least one game designer wants to see this happen and we are not in the business of limiting the engine before we leave the starting gate.

I did have the notion of writing some quick speed prototypes to compare the extra performance hit from turning the two dimensional array access into a hash table access approach.  What this means in real money is that instead of a fixed level limit of 500x50x500, you would have an effective level size of around 99999x99999x99999 and a lower memory footprint as we would only expand the hash table as new reference elements where added to the map. Sounds great in theory, but where an array access can be less than 50 cycles to complete, a hash table interrogation could take thousands of cycles, and when you then multiply each write/read by the iterations demanded of the current system which constantly creates the level as you go, it might start to impact on available cycles for the rest of the engine.

I am also warming to the benefits of dropping baked lights altogether and opting for a deferred renderer that only uses dynamic directional, spot and point lighting for the entire scene.  The biggest win is that the memory footprint will be smaller and the lighting results when editing and playing much better. The potential downside (or disaster) is that performance will be such that only dedicated graphics cards could run with all features switched on. Some good news about referred lighting is that you can gain more performance (quite a bit more) by simply reducing the display resolution as the lighting is based on how many pixels the screen space has to deal with, so you can get some great visuals on an average PC by simply shrinking your display. It also means we spend more time on forward thinking technologies, and less time on legacy solutions, which ultimate future proofs the engine for years to come.  The deep thoughts continue...

5 comments:

  1. I'm really impressed with the amount of thought you are giving FPSCReloaded. If this remains throughout the entire development I think we could really see some enormous advances in the project.

    I shan't lie, I am not great in the technical field of programming and this lightning system is not entirely clear to me. I think unless it is tested we cannot truly see the impact on performance for the game. From what I've read, people seem to think it will hit the performance rather hard, but perhaps we need to look at this relatively. People who we target out games to are not going to have the machines they did years back when FPSCreator was in its prime.

    If this technique of lighting is quite commonly used then I see no reason for it not be the system that FPSCreator Reloaded uses.

    The only major thing that I want any lighting system chosen to do is to be capable of rendering dynamic shadows and spotlight cones so an industry-standard flashlight can be created.

    ReplyDelete
  2. I'm really pleased to see Lee is going with a deferred rendering approach. It makes sense in a lot of different ways.

    FPSC has always needed dynamic shadows for it to be considered a true modern game engine so that is essential to this version.

    I think the approach being taken is sensible and the right choice. Lets not improve every other aspect of FPSC and then stick with the old static lighting and shadows. That would be a huge mistake.

    Getting the lighting and shadows engine done correctly now is a high priority.

    ReplyDelete
  3. Deferred Rendering does not say we get dynamic shadows.
    I would love that feature, but that's not what a deferred renderer does exactly.

    But I hope we get up to 8 dynamic shadows by lights of the renderer so

    ReplyDelete
  4. I'm happy with at least one dynamic shadow source (closest to the camera). In fact best to leave it configurable in the settings.

    ReplyDelete
  5. We need the maximum number of lights and shadows to be configurable (no maximum, entirely up to the user).

    ReplyDelete