Wednesday, 19 June 2013

Wednesday Obstacle

Two Missions

I had several little tasks today, with the two largest being a major update of my Reloaded development schedule so I can plan and track the remaining part of this project, and to move the shadow goodness into the map editor so I can see the shadows in a live-editing setting.

The Schedule

Creation of the new spreadsheet went fine, and I was able to plot out in detail all remaining tasks required including Terrain, AI, Physics, Encryption, Module work and testing.  I have planned for October as per the original deadline, but with the 'extreme research direction' we've been going that deliverable will be a stretch. I am still aiming for it to put myself under some healthy pressure but I am not too concerned if I step over the line a little. As long as I can put some great game creation software in your hands by Christmas I will be happy.

The Map Editor Shadows

Now this one was (and still is) a pig. I moved over the few bits of code which would have allowed shadows to spring to life, placed the light somewhere suitable and presto, nothing. No shadows, nada. Okay, I missed a value somewhere, back I go. The best part of five hours later and I am not only still finding the solution, but the underlying problem is the maddest one I've seen in over ten years of DirectX coding.

The spheres you can see are placed there for my debugging efforts, the problem is the orange rectangle in the top left which seems to only want to render the first 256x256 units of the object universe. Not only that, it wants to render it upside down, untransformed and use incomplete UV data.  That red to yellow stripe is actually a pixel shader plotting the UV coordinates as the RG of an RGB colour.  Clearly, it has an issue interpolating the R from zero to one and just sticks at ONE. Grr.  The bottom orange square was an early image were/where I managed to get 'something' from the spheres I was rendering, see the few pixels in the top left corner.

My best guess right now is that unlike my prototype, my main engine has a much more complicated shader hierarchy and somewhere along the way the engine is messing up the shader I am using (identical shader works fine in the prototype). It seems to take in the raw model coordinates fine, but extra things like constants and secondary vertex data seem to be missing or partially incomplete.  I've checked everything four times and the code looks just as it should. Furthermore, I am running out of clever ideas to trick this shader back to life.

Lee's Last Stand

I have one more trick up my sleeve which is to transplant the entire prototype inside the engine code (as is) to get the exact object set-up working and casting shadows. Once I have shadows, I slowly remove the prototype objects and introduce the engine objects until something breaks. When it breaks, whatever I transposed last is the culprit.  No doubt this issue will take me into the early hours but it will be worth it to see shadows being cast in real-time as you add and remove segments, rendering using a gloriously cool parallax depth mapper.

Signing Off

I've been waiting for a few deliveries today, and one of them was the game S.T.A.L.K.E.R which was one of the classic examples of excellent deferred rendering in it's day.  I have decided not to implement deferred rendering until I get back from my holiday, mainly because I want to continue working on the shader, the shadow system and the new artwork coming from Mark to create a nifty demo to leave you all drooling over.  Deferred rendering is simply another way of solving the lighting question in a game engine. If I can get the current forward renderer producing fast shadows for outdoor and indoor use, and get to keep my parallax mapper for universe rendering, we may not need to defer at all. Performance will be the key decider here, so let's carry on with the eye candy and see were/where we are when we decide to stop adding.  I was almost tempted to add depth of field and bloom to the prototype, then stopped myself in the nick of time. Plenty time for final polish once the guts of the rendering engine are running fast!


  1. Back when I worked with the FPSC Source I got some problems with rendering world normals and such stuff on segments in FPSC. This was the result of the static objects system I think and the way shader effects were applied to the object.

    Don't know if this matters in some way, just my 2 cents.

  2. I'm sure you'll find the problem and fix it, it's just a matter of time.

    And I wouldn't worry too much about where/were. In your north western accent they both sound the same anyway.

  3. Look, I know people generally dislike people correcting grammar and spelling, but I firmly believe that it's very important to know how to spell, so I will continue to correct people. Lee, my point is, you should at least make an effort to try to memorise the correct usages of "where" and "were".

    Were = past form of the verb 'to be' (eg. "We were at the shops.")
    Where = refers to a place. (eg. "Where will you be tomorrow?")
    We're = contraction of we are. (eg. "We're going out.")