Well, I haven’t updated for a while mainly because as I said previously I’ve been quite busy. Work has slowed down while my family are over as I’ve been out and about with them but things are still looking good.

I’ve just found an old video I recorded of the Demo Harness in action back in May so I’ve put it online here (WMV, ~4.6MB, Right click and “Save link as…”). It is hard to explain to non-technical people, but what you see in the video is not directly the demo harness itself, but rather something developed using it. My current demo showing off the harness is pretty different to what you see in the video. Maybe one day, if you are lucky, I’ll show you it.

Also, I just noticed that my spam filter has been filtering out all recent messages from Mike of Mono Effecto fame. Sorry Mike! I’ll email you later when I’ve got some sleep (it’s 6am currently…)! Everyone else: Go to Mono Effecto’s website and register to get an exclusive download-only new single!

EDIT: Just noticed that in the video although I mention using an Oren-Nayor shader to render the floor, the floor is actually missing. Oops. Oh well. I can assure you that my Oren-Nayor shader looks lovely though.

Well, it’s twenty to six in the morning and I’ve just finished mopping the floor of the corridor outside Karin’s and my room. It’s obviously a slow time of the day.

I’ve got another coffee shop article to upload on shadow map packing but that will have to wait as it’s not on the computer I’m using now and it’s too early in the morning to copy it over. I have a bit to change in the last article (on the frame light buffer system) before I polish the layout up for a proper release.

Tonight (well, last night now) I finished replacing the texture management routines in the Demo Harness to use a templated resource handler I wrote the other day that implements much better reference counting and garbage collection.

I’m very pleased with the way it turned out as it paves the way for larger demos using the Demo Harness and eventually maybe even streaming textures from disk. I’m planning to extend the usage of the new resource handler to manage materials, effects and meshes eventually, but for now just using it for textures will do. Eventually I will also put up an article on the technique used as it is quite useful for a variety of purposes.

Right, now I have to decide whether to sleep or watch Magnum PI….decisions, decisions…

I have finished the first draft of an article about my implementation of shadow maps within my Demo Harness system - “Lighting - Shadow Maps and the Frame Light Buffer DRAFT 1“. I have yet to add in the numerous references I have used and I want to re-write various bits but as it stands it contains most of what I want to say. As the title suggests the article deals with my use of a secondary buffer, a Frame Light Buffer, to hold the results of the percentage closer filtering performed on the shadow maps together with various implementation details (nothing too specific, mind) and further extensions and optimisations. I’m reasonably happy with it but it can be improved a bit. Any comments would be appreciated either in the comments section or via email (mike -at symbol here please!- mikesspace.net) .

I actually wrote the first section sitting on a train from Stockholm to Uppsala and the rest in a coffee shop in Uppsala (Cafe Lion if anyone cares!) as I borrowed my Dad’s ultra-cool JVC sub-notebook computer during my last visit to England. I already have a super-duper laptop but sadly “super-duper” translates into “weighs a ton and sounds like a jump jet” with laptops…

EDIT: Oh yeah, the layout is also not finalised on the draft. I’ve had a few problems getting used to laying this kind of article out in wordpress.

For the non-technical of you out there this may bore you! (Also, to clear up any confusion particle systems are often used represent explosions, sparks, smoke etc.. in games.)

I’m not sure if I mentioned that I completed the virtual machine for my particle system the other day. You can create and manage particles without using the VM if required but it is a nice addition to the functionality of the demo harness. Just to recap, the motivation behind creating a VM for handling the initial and ongoing creation of particles was speed. Lua is fast, but not that fast. Repeatedly calling lua script functions (as would be required by a custom particle effect generating new particles every 10th of a second say) is slow. I wanted to maintain the data-driven nature of the whole demo harness with the particle system, so using a VM was a good way to go. VM programs can be defined using lua script (using a scripting language to define a program in another scripting language…) and are interpreted by the native code VM as required.

The VM is register based, the initial stack based plan being overkill, and it’s instruction set resembles the Direct3D vertex shader set. For anyone who is interested the current instruction set is included below. I have not included any instructions requiring “forward jumps” for simplicity although I am considering adding instructions such as If and For and maybe simpler instructions such as Compare.

The set of registers available is as follows:

• 8 Input Registers (set before the VM is first executed)
• 8 Persistance Variable Registers (can also be given an initial value. Value persists between code executions)
• 16 Tempoary Registers (value does not persist between code executions)
• 7 Output Registers (no read access - for new particle pos, size, UVOffsetSize, velocity, userData, userDataVelocity, timeSpan, size)

The registers themselves are type-less. A value carries it’s own type with it, with supported types being a single float, a vector(dim: 4) or a matrix(dim: 4×4). Not all instructions can operate on every type of course (e.g. Cross only applies to vectors, as does Dot).

In addition to specifying constant values for the input registers you can also specify a generic property. A property is a concept used in the demo harness to allow objects to expose values as objects themselves with either read, write or read-write access. This allows you to (for example) create a particle generator for a missile smoke trail that generates new particles that are always behind the missile in the correct position and is quite a powerful tool and also helps to keep everything data-driven from the script side. Input registers set to a property have their values samples at the at the start of each execution of the VM code.

The VM code is stored in an array of bytes, 1 byte per instruction. Arguments following an instruction consist of one type byte and a variable number of bytes following. Arguments can specify a particular register or be a constant value (again float, vector or matrix).

The VM itself is a fairly simple affair using utility functions to acquire the value of the supplied input arguments, a generic value structure for performing basic artithmetic between arguments of differing types and another util function to store the result in the supplied destination.

I haven’t really optimised the VM yet but already it runs at a very suitable speed. The initial optimisation I may make is to align constant matrices and vectors to 8 or 16 byte boundaries in memory for faster handling (when using SSE\SSE2 etc…).

In addition the the functionality provided by the VM, the general particle manager also supports groups of particles having their own individual velocity and being affected by gravity. The particle manager also handles things like sorting the particles based on distance from the viewer if required and sorting groups of particles by material type for reduced state changes.

Some screenshots will hopefully follow soon, maybe even a small video, after I’ve finished moving appartment.

(Hmmm. I’m having issues getting the below to come out correctly. Bear with me.)


The (Current) Particle VM Instruction Set:
// Basic Commands
Move // [ins] [dest] [src]
SetComponent // [ins] [dest] [component] [src]
// [dest] is a vector, [src] is a float
// Sets component [component] (0-3) of [dest] to [src]
GetComponent // [ins] [dest] [src] [component]
// [dest] set to a float, [src] is a vector
// Sets [dest] to the component [component] (0-3) of [src]
SetFrequency // [ins] [arg]
// [arg] is a float, in seconds.
// Particle Commands
SubmitParticle
// Arithmetic
Mul // [ins] [dest] [src1] [src2]
Div
Add
Sub
Dot
Cross
Normalise // [ins] [dest] [src1]
Length
LengthSqd
Cos
Sin
Tan
// Looping
Do // [ins]
WhileLT // [ins] [arg1] [arg2]
WhileGT
WhileEQ
WhileNEQ
// Generation
RandomFloat // [ins] [dest] - Sets dest to a random float between 0 and 1
RandomVec // - Sets dest to a random vector with each component ranging from between 0 and 1
RandomVecCube // - Sets dest to a random vector with each component ranging from between -1 and 1
RandomVecSphere // - Sets dest to a random vector representing a point on a sphere centered at 0,0,0 with radius 1
// - (Correct random distribution)
RandomInt // [ins] [dest] [arg]
// - Sets dest to a random whole number float between 0 and arg.
// System Commands
Exit // [ins] - No need to use explicitly.


This is a bit of a hotch-potch of technical details on how I am currently going about working on my portfolio demos, written very early in the morning. Mistakes may be abound!

I am working increasingly more with content rather than code as I near the end of my main portfolio demo. This is something relatively new to me, having to spend proper amounts of time tweaking things so that other people, besides me, can understand what is going on. It is actually rather satisfying once you get used to the tools you are using. For scene composition I am finding it useful to first mock up a rough model of the scene I am working on, before starting to model the final scene and gather the final art assets. Wings3D is my application of choice for quickly blocking out a scene as it has a fairly “no-nonsense” interface and is quick to use. Once I have my mock-up I can check that my planned camera placement\movements will work etc…

The mock-up itself is usually based upon (fairly detailed) notes I have previously written (usually in a coffee shop somewhere in Uppsala) together with annotated plan-style sketches. In my notes and annotations I include details such as graphical effects used for each surface, any physical behaviour required, any game-logic related behaviour required etc… From this I can build up a set of three lists: Required Materials & Visual Effects, Required Physical Rigs, Required Entity Script.

The final model geometry, as I mentioned in a previous post, is modelled in a mixture of Wings3D and Truespace. I usually group the model surfaces in Wings3D based on their desired material so that I can easily apply the final materials in Truespace. For each required material I use a makeshift texture map, looking as near to the final material as possible, to texture map the model in Truespace. Each makeshift texture map shares its name with the material it represents. The model is then exported to the D3D X format and when loaded by the demo, the makeshift texture names are used to lookup the final material from the material library.

I then create the dynamic entities and their physical rigs in Truespace and export (to lua script) ready for use. Final entity behaviours are scripted in Lua and tested, and converted to native C++ code if speed becomes an issue.

Material creation breaks down into two steps: Choosing\creating a visual effect and Choosing the various image maps and options to be used by the effect. If the required visual effect already exists material creation just boils down to tweaking a few parameters and choosing a set of maps to use (base, normal, gloss, etc…), otherwise creating a new visual effect from scratch can be quite time consuming.

Currently the main surface shading styles being used are basic lambertian, phong-style metal, simplified oren-nayor and a transparent water-like effect. All support cube-map based ambient light lookup to prevent shadowed areas from appearing “flat” and shadow-mapping (casting and receiving). Support is also build into the “standard” shaders for transparent objects casting shadows (more or less) correctly.

Below is the current mockup I am working off to create the scene for the final iteration of my main portfolio demo. Hopefully, when the demo is released you can see how faithfull I have ended up being to this mockup.

I haven’t posted an update on the current status of my work recently so here it is.

On a non-work related note Karin has been ill for the last few days, and even after a trip to the hospital she feels no better, still being sick often. And Karin has her end of year University exams this week. She is working away well though, bless her, so I think that she will do fine but hopefully she will also start to feel better soon.

Work is going at a reasonably satifactory rate at the moment. Taking a break from the more graphical elements of the demo harness system I spent a couple of days integrating the Novodex physics engine into it with very pleasing and rapid results. I enjoy working with physics simulations in general, having written a particle based physics engine a couple of years ago now (I think), and I evaluated the first version of MathEngine and a few others a few years back (Interestingly most of the ones I evaluated have now gone bust or been bought up). For a while now I have had my eye on Novodex as a suitable candidate for integration, often perusing the manual and checking out the latest version, and it seems I have made a good choice. The quality of the simulation seems solid, providing you deal within a reasonable number of constraints (keep gravity lowish, keep the ratio of masses between two jointed objects to within a factor of 10 etc…) and the API is nice to use with only a few bug-bears.

Created entities in the current scene can be assigned custom a behaviour object that handles responses to various events and messages, you can even use a lua script object to handle responses to one, some, all events if you wish. This allows for fast prototyping of entity behaviours in Lua script before commiting the behaviour to faster native C++ code seamlessly.

The current tool chain I use for 3D content is to model in Wings3D, touch up in Truespace, texture in Truespace (usually) and then export to a D3DX .x file for use by the demo harness. This fitted in nicely with the introduction of physical properties as I have used a Truespace plugin I wrote for my SmallWorld engine, slightly modified, to allow me to define physical bodies and their collision shapes in Truespace together with any joints acting between them and export them to a Lua script for use in a demo. This is working suprisingly well, with objects like “wobbly bridges” being easy to model. The plugin and script also supports creating “instance-able” entities which is quite cool.

I would point out the Truespace is not what I would recommend for this kind of work. It is, in my opinion, a rather second grade modelling program, but as I already have a license for it (and little - or no! - spare cash) it is what I am using.

I still have a few last joint types to add support for in my Truespace plugin but no major work.

I have also just finished the foundation for the particle effects system for the demo harness (just implemented as a custom controller object) and I am about to work on the next stage of a basic virtual machine to allow for flexible and scriptable (custom VM and not Lua for speed) particle generators (for things like explosions, missile trails, dust etc…).

So, I guess it is going well. Some pictures may appear sometime soonish, maybe.

Mike.

While my parents were sorting out their bedroom they found a disk containing a backup of what I think is the first graphical game I ever wrote! It was a 2D platform game (called “Sprog” for some reason) written in C++, compiled using Borland C++ 3 or 3.1. The archive dated from 1994 but I have a feeling the code was originally written in 93. Sadly no executable is present and I will have to dig out my old Borland C++ 3 disks to compile it, but still it is pretty cool to find it after 10+ years!

It is amazing how things change. Sprog used a screen resolution of 320×200x8, approx 0.06MB a screen. Today, frame buffer sizes frequently top 4MB! Also I had to smile when looking through the code and found the section marked “Detect VGA Card”! Ah, things were so simple then!

Well, I’ve finally got back to some 3D coding in the last 2 days. About time too!

I wrote some architecture code for the landscape system of the Scorched Christmas 2 project that I am now involved in (The code is not checked into CVS yet, but will be sometime soon). I haven’t worked with landscapes for a while so it was a nice change.

I plan to finish off my “water” demo this coming week and then I plan to refurbish my demo harness to use my own existing 3D library more instead of D3DX as my own library (called “plex”) is quite complete and provides some useful functionality that is not present (and not in the remit of) D3DX (like physics & various collision detection operations). I am having issues with how to generate the ocean water for the demo. I’m not sure of the best way to go as it needs to be fairly flashy but due to it’s size you cannot do some of the funkier things with it. I think I may end up creating another water based demo showing a smaller scale body of water and interactions with it. Jos Stam has written some interesting papers on this topic and I have wanted to play with his ideas for a while now.

The sudden stopage of blog entries is due to the fact that I have been working like mad on a number of things. I have started Swedish language lessons now (which are going very well!) and lately I have stopped work on my major project SmallWorld to work on a couple of smaller more job-specific demos for various job applications.

So far everything is going brilliantly. I have written a demo framework based around DirectX 9 and LUA (called Project Clover so far) and that has proved amazingly useful. I can now put together quite complex graphical demos very quickly. There are still a few things left to do (specifically a controller system) but it is working & usable. Now just to finish it and get a job…!

Behold! An early WIP shot from one of my new demos:

I have been playing Centipede (info, screenshots) on my Atari 2600 for the first time today. It is amazing how well it stands up in gameplay to modern games (I guess there is no reason why it shouldn’t really, but it is still suprising). What caught my attention most with the game is the clever gameplay mechanic it uses. Every element of the game puts the player in the position where they have to balance risk against reward.

Do you want 900pts for shooting a spider? Better shoot the spider point blank. Don’t like the risk of a point blank shot? Shoot from a distance for 300pts.

Want to slow down the centipede? Then shoot the mushrooms in its path - but get less bonus points when you lose a life. Want more bonus points? Then leave the mushrooms on screen and handle the centipede’s rapid descent.

When you die you usually feel that is is your fault. You were too greedy and took one risk too many. Note that this feeling plays alongside the more typical feeling of either the game being too hard or that you are not good enough to beat it, but it has a very different effect on the player. Almost always it gives players the “just-one-more-go” syndrome. Not many games manage to get this across well and it is nice to see such a perfect example that was originally released way back in 1982! (I was just one year old then!).

While many modern developers talk of the risk-reward balance, very few games made lately seem to show a good approach to working with the risk-reward balance in-game. Many games present players with a choice of performing an action with a fixed risk-reward balance: Should I go down the pit with the spiders to get the gold or not? What is great about Centipede is that it takes this binary descision and makes it analogue: (In the case of the earlier example) How many spiders can I take on in a pit, given that I’ll fine 1 gold coin for each spider. This acts to involve the player more in the game as the player himself (or herself) becomes the one defining the difficulty landscape of the game.

I really enjoy playing games based around a core mechanic, and Centipede is one of the best examples of this I have seen in a while (even though it is 22 years old!).

Right, back to work!