- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- May 2005
- April 2005
Category Archives: code
In my recently released game, Button Battle, I opted to use RakNet to implement simple networked multiplayer. I figured I should talk a bit about how that all went, since I would have enjoyed reading such an article myself… and frankly, I’m going to forget this all soon and I will have to read it [...]
As promised, here’s the source code for Button Battle. As everyone should expect, it’s not the cleanest code, but I do have plenty of experience and it is commented. I expect that the code might be a valuable resource for people who want to see how things were done. To that end, I also made [...]
TinyXML is a great little library (tiny, even) for loading and parsing XML documents. Here I’m going to introduce the basics of getting all your data out of (and into) XML files. Part 1 is quick and simple. In Part … Continue reading → Continue reading
Sadly no pretty pictures, but loads of progress. That’s the sad truth of programming, loads of boring text before anything cool happens.
So what are you seeing
- Query Response Format working
- People, Locations, Objects populating with random generator
- No Events Yet
- Generic Time Atom System in place for storing time sensitive data
Next steps are to intelligent filter choices based on context.
Also I want to add an output to a file so conversation is visible.
So I wrote this long article about how I switched to an Atomic data model.
How this is one possible implementation of the proposed model. Different code would be written based on language, memory and cpu restrictions. The implementation is a proof of concept. It does not define the model.
The atomic model uses a damage protocal. It stores a value and the time that value was set.
- Testing point before any atom returns unkown.
- Testing between or at an atom returns last value change
- Testing past last atom return last known value
Blind Spot & Discovery
This system means if a value change occurs and then is changed back before an agent observes it again then they are unaware of event. If however the observed value is different to the last known value then they agent knows an event has occurred and can inquire or investigate.
Anyway I got to run and catch the bus, sorry for short version.
Cube Maps Ahoy
So there is a slight glitch with the reflection but ALMOST there.
So for those of you curious I’m throwing down some water rendering magic. Not to mention real-time environment cube mapping. Behold the result.
So it’s broken and the ocean needs some motion (pun fully intended). I also may be slightly sleep deprived… but onwards and upwards.
Shadows are EVIL!
Okay above you see rough and blurred. The rough pass uses a single sample against the depth buffer. Those bloody pixels are a result of the resolution of the shadow map.
The blurred insanity is a shadow method called PCSS, based on the White Paper, “Integrating Realistic Soft Shadows into Your Game Engine” by Kevin Myers, Randima (Randy) Fernando, & Louis Bavoil. Sadly some of there stuff uses Shader Model 4 so I did my best approximation.
Not happy with either method… pulling my hair out.
To Debug it… Draw it
Many people will tell you this but whenever you have a problem try to visualise it. This can be applied to almost everything (except cases where visualisation is a constraint, think advanced maths and quantum). So above you see the debug frustum.
Well after fighting with all these various problems I’m thinking to myself… I need to double check my Frustrum. Five minutes to write and BAM problem is instantly visible. The problem I was debugging for 5 hours solved in 5 minutes.
Printf & Debug Draw rocks.
Problem: Shadows giving strange LightViewSpace results
Well the problem manifested in many ways. I was debugging shaders and tweaking render targets. Not to mention twiddling the depth bias so often that it was indecent.
The problem was two fold. Firstly the sun view & position didn’t match up. The result of a quick hack to get the sun in the right place, hacks bad. The second issue was todo with the scene bounds.
The view matrix is built with a look-at call. Well the key is that the centre of the bounds must be equal to the look-at target. Why is this? Well draw some random shapes on an A4 page. Now draw a circle which contains all those objects. Now measure the radius of the circle and draw a square at the centre of the page with double that length per side.
You see the problem, unless the circle is at the centre of the page their will be bits of it outside of the box, which means they won’t be shadowed.
So you compensate for offset and increase the radius. To do this instead of measuring the radius of the circle measure the distance from the centre of the page to the furthest point of the circle.
Before you ask we can’t move the box from the centre of the page as that would change the angle the light was coming from.
Onwards and upwards.
Progress, the shadow is low quality due to PC card limits. I need to add some bias to avoid flicker, and smooth off the edges to get soft shadows.
So climbing into bed last night I got a great idea.
Debug the Light ViewProjection matrix by using a camera with the same matrix. Well you know how I managed to knock together that skybox so quickly. Well I dug into it…. YIKES.
I managed to get the sky shader down from 64 instructions to 27 instructions, and remove 4 branches. Sadly the sun doesn’t look great. On the bright side the Sky Sphere now respects it’s World Transform. Light amount now tied into horizon. Removed that horrible change line. Lost the tinting.
So this is what happened…
Oh wait I can clean up those 2 lines quickly… later… Hmm this could be improved… later… wasn’t I meant to be coding something?
Yeah so now after all that fiddling, I’m now working on the shadows again.
Shadows and Reworks
So after a lot of thought and planning yesterday I set about implementing soft shadows using shaders tonight.
Sadly this meant I needed to re-haul the entire scene manager and packer to support texture swapping, and effect management. I also had to write a big ass shader to do several things, and optimise.
That’s done, now all I need to do is add the Shadow Render pass and it all should work. I’m going to miss the last bus home, so I gotta run.
Lights Camera & Action
Well lighting & shadows are a complex bag of trickery and maths.
Basic Lighting is simple. Take a book outside into the sun now rotate the bugger around and throw it. You will notice the amount of light on a surface can be measure as an angle between the light direction (from the sun) and the facing direction of the surface. A very cheap and easy calculation we love, called dot product.
Now shadows are more complex. Light as a physics based thing in reality is a crazy thing which drove Einstein insane. For instance do you know light is affected by gravity so it actually bends around objects forming a very distinctive halo effect. So not only is it a ray cast but it’s a particle/wave which is affected by gravity fields. They also split up and bounce all over the place.
Now in games we fake it, cause those calculations are really expensive, and most times we care more about whether a bullet hit a guys head.
A cheap and simply trick is to back the shadows. This works well if the lights & geometry don’t move much. Even in AAA games with more advanced systems, baked light maps do a lot of the heavy lifting.
To bake it we basically do the calculation before the game runs. The simplest form is a flat planar map, some bake a projection map and some cases even bake shadow volumes. We can animate the baked textures and get some awesome effects.
Okay so we have this bad guy, race car or some other object in the world. Well we can forgive a lot with our suspension of disbelief. What if we glued a “blob” shadow to the feet of bad guys or race car.
You would be amazed how many games use this system to optimise thing and it looks great.
Well if we simplify light and ignore the bending, bouncing, and craziness of it, then we can treat it as a straight line from the light. Now we like planes, planes are really nice simple flat things.
Okay so now we have this thing called the projection matrix which is part of the matrix of projecting a 3D object into a 2D image. Well if we use the same trick we can clone an object, then squish it into a projection and render it all black. We have a shadow, Peter Pan Style.
Okay well know in reality we need to drop shadows onto complex geometries. Now we also have this wonderful shader pipeline. Before we render the scene we render the entire world from the perspective of the light (as we would the camera). We then grab the depth buffer and save it.
This needs to be done once for each light.
Now this makes an image of how far the beam of light travels. Which we pass in to the next render pass, along with light matrix. Now if we take a point in space transform it by the Model-View-Projection as normal. Also Transform is by Model-Light-Projection. Then we compare the MLP read-out against the baked texture we can tell if the light reaches that point or not.
Another way of doing Volume Shadows is to use Stencil Buffers, this is the traditional way to do things and how most shadow volumes have been done in the last 10 years.
Day & Night Cycle
Woot! Not only did I get a pretty awesome Sky-Sphere in place but I also managed to knock up a day/night cycle. I also cleaned up the shaders and have global lighting in place.
Found an awesome tut, and manage to knock the shader up from that.
Next thing is to look at shadows, but don’t you think that is preeety.
Shop Blimp – Love Programmer Art
Shop Internals, rendered in wireframe
Ye gods captain, PROGRESS.
After the dismal run around the pointlessness I have actually made some progress last night and today.
- Coupling Issue solved with Interface
- Island has day/night cycle
- Shop Blimp interior & exterior modelled
- Blimp added to world
- Add a reliable help to translate between tile and world space
- Started work on Sky Box
Okay so we don’t want the model (island & prop data) coupled to the view (scene graph, animations, models). Well the solution was to give every node in the scene graph a user data element which had an interface.
The core functions being, Update & Pre-Render. Further functions and event handles can be added to the interface to handle animations and the like. The interface is the façade which prevents tight coupling. Neat and clean, kicking myself for not seeing this solution weeks ago.
My reason for posting, indirectly. I waster the last hour or so trying to generate normal & height maps for clouds. Reading up on things I already knew how todo if I stopped and thought for a second. The moment I saw my folly I stopped to write this to break me out of it.
I will now grab some food then hopefully not be stupid.
The big choices I’m facing at the moment and playing around is on two fronts, GUI Behaviour and Render Pipeline.
Fighting through some choices… will post more shortly
Staying late at work to do university work is REALLY awesome, and so works. My work setup is just so much better for coding.
- Pro vs Express
- Two Screens desktop vs Laptop
- Work vs Bedroom
Anyway, getting the island render stuff in. Sadly I need to catch a bus home but I’m hoping to crack on with purchase & place items.
Created World[Game World] Building Basic Prop [Template] Frank.Island.WorldProp Building Basic Prop [Building Template] Frank.Island.Building Building Container Prop [Container Template] Frank.Island.Container Building Inventory Prop [Inventory Template] Frank.Island.Inventory Building Ingediant Inventory Prop [Ingrediant Template] Frank.Island.Ingrediant Building Tool Inventory Prop [Tool Template] Frank.Island.Tool Building Food Inventory Prop [Food Template] Frank.Island.Food Added Obj[Island] to World[Game World] Added Obj[Hand] to World[Game World] Added Obj[HandCam] to World[Game World]
It might not look like much but that little but of text output proves the hacked type system works. It’s horrible, sadly I’ve wasted a weekend trying to do things the “correct way” and failing.
If I have time I want to investigate alternatives
// Horrible HORRIBLE System!!!
// Possibly replace if time permits, or else gourge out my eyes in shame
// Game Gems 1: Magic of Data-Driven Design by Steve Rabin
// Game Gems 2: A Game Entity Factory by F D Laramee
// Reflection and C# System.Activator.CreateInstance(…)
// See: http://forums.xna.com/forums/t/39891.aspx
Ah well it works and I have a meeting with my supervisor. Hopefully by tonight I will have that Tree & Oven in game.
I really wish I had a pretty picture but I don’t. Sadly it’s a problem with grunt coding tasks is there is very little pretty to show for it. In fact most of my work today has been in the Content Pipeline which runs at build time. So its not even runtime code.
The XNB system in XNA is great but I had a few hiccups with it. I still don’t think I’m using it in the best way possible. However after ripping up tons of pages of notes I’ve gone with the best solution I can currently think of which no doubt has loads of problems, besides some of the ones I’m already seeing.
Model View Controller
Soooo sooo easy to be a naughty coder. However as this is an academic project and I can be slightly OCD even with production code I’m following it as MUCH as I can. The controller is slightly too coupled to the state which it controls but de-coupling is more messy.
Always always realise the so called “rules” of software engineering are generalisations and guidelines. You should never break a rule without first understanding it. They need to be flexible and you need to be flexible because the key factor which makes someone an engineer is a way of thinking, analytical problem solving.
A decent education in engineering is mostly about how to think. The tools you use are easily learnt but it’s the process and thought model which is hardest. I think that’s why you see so many true engineers have cross disciplines.
Well now that a lot of grunt work is in place. The goal for tomorrow is to have the following working.
- Tree Prop – Loaded from Data, Go through full life cycle and interaction
- Oven Prop - Loaded from Data, Go through full life cycle and interaction
Bigger than it sounds
So after the coupling issue I’ve been looking at Object Factories and inventories. Now something I learn to love more and more is Data-Driven development. I cannot express my love for it highly enough.
Also thanks to the amazing work of Shawn Hargreaves and all the XNA folks we have automated reflection and xml processing. Which let me tell you is just MAGIC!
The problem I’ve been battling with the last few hours (other than sheer amazement at how awesome the XNA system is) is defining the data structure and whether the class itself should be spat out or a data format, or settings style system is more appropriate.
So the solution as I have come to found a lot recently is use case. Before you build the system, write a scenario, set of rules, or list of items. Then use those to drive the devolpment.
As I often have said to the team on our new project at work, which is on a very tight schedule, make a choice and be definite. It’s okay to be wrong, but imprecise and fluffy is unforgivable.