Jump to content

  • Log In with Google      Sign In   
  • Create Account

Not dead...

Moving, keep on moving...

Posted by , 29 July 2010 - - - - - - · 212 views

So, about 4 weeks ago it was about 4 weeks until I move... now in less around 48h I should be moved.

So, the catch up;

On monday I start work at Codemasters just outside Southam/Leamington Spa for their action studio. While its a shame to be leaving Brighton I'm looking forward to the change and working at a different studio.

The biggest hastle has been finding somewhere to live, however after 3 trips up and various false starts I finally found a place to live and got confirmation that I could have it yesterday (wednesday) ready for a move in on Saturday!

So, right now, what little hasn't been unpacked in the last 2 and a half years is being packed up (mostly new books and games it seems) ready to be put in a van and transported from Brighton to Southam on Saturday.

Intresting side note; Southam will be the furthest I've lived from the sea in my life. Ipswich wasn't too far away and Brighton is a seaside town, but Southam is pretty much central England so that'll be new.

So, that's the story so far...


Posted by , 04 July 2010 - - - - - - · 243 views

So, despite being on garden leave I've not really had much traction on my projects.

I blame IRC.
And Company of Heroes.
And the World Cup.

So, what have I done?
Well, to start with I've broken a few things in the particle system. After I got the fading working I decided that I was processing too much data; after all each block of 4 particles used the same lifetime information so I was storing 4 times too much information for life and max life.

In trying to reduce this I've made a bit of a mess of the code and, somehow, broken the fading code and the life time code infact so I need to look into that.

I also decided that the method I had for configuring effectors for the particle systems was... poor. Each group of 4 particles was taking at least one indirection per effector and when this list doesn't change (or at least 'changes rarely') this isn't a good solution.

I do have the start of a solution however I'm going to keep quite on it until I've had a chance to a) fix the particle system and b) implement the idea.

I think its a good idea, its an idea I've not seen done yet and above all else its an idea I'd like to get working so that I can write an article about it, either to be book published or gd.net published, well see. (I feel its been too long since I've had my name in a book [grin]).

The other thing going on of late has been The Job Search.
I had an agency on the case, a very good agency in fact, and the guy I was talking to there managed to get me 8 interviews (phone and face to face) down in a very short period of time; and that was beyond what I thought I'd get as I thought I'd get 3, maybe 4, interview offers at most.

Most of those have resulted in "no go" for various good reasons.
I have, however, been offered a position. I won't say who just yet but this does mean that I do have a job in the near future.
Part of the reason for not saying is I'm currently waiting on the results of a face-to-face interview I had friday morning and to see if a 3rd (and final) company are going to want a face-to-face before I fully agree to anything.

What this does mean however is that, at some point, I'm going to have to quickly find somewhere to live as it looks like on the 31th of July I'm moving house to some other part of the country. As to where... well, we'll see how things go this week...

Still, 4 weeks until I move...

Random numbers are the devil!

Posted by , 05 June 2010 - - - - - - · 216 views

So, as my last post mentioned I had integrated some random number generators into my particle system and the results were very pleasing; once I had the code I could fade particles out with random 'group of four' life times and all was good.

So, I decided to test for speed the other night and hit a slight problem; trying to spawn 1,000,000 particles introduced a 10 second pause in the test app o.O

So, I fired up the beta of Intel's Thread Profiler and set it to work to find out where I was hitting a hotspot. Turned out all this time was being spent in either the forces generator or the ages generator.

As the code was pretty simple, apart from the random number generator, I played a hunch and removed those calls. BAM! Suddenly 1 million particles took pratically no time to spawn.

The solution to this problem; a good old lookup table.
Currently I'm generating two tables of 1,000,000 values each, which is good enough for the testing process at least, but I need a better solution if I plan to use this in other cases.

Chances are 1,000,000 numbers will do me, I just need to think about how to cycle through them when being queried from multiple threads.

Either way, right now 1,000,000 particles takes ~1second to spawn and thrashes the frame rate; I suspect the latter is down to me trying to send 22meg of data PER FRAME across the PCIe bus to the card to render [grin]

I'm going to ponder on a better solution to this problem while also pondering on possible D3DCompute solutions as well. To be honest, really what I want to do this is a new Fusion processor, but those aren't due out for another year [sad] then I probably could throw 1,000,000 around with no problem [grin]

I also need to put proper timing in so I can see how long each segment is taking under different loads, and fix this update problem I have where if you spawn particles after the first trigger it seems they die quicker, but only until all previous particles are dead [oh]

(As I'm now on gardening leave I've got plenty of time to work on this, yay!)

Particles and Unemployment

Posted by , 26 May 2010 - - - - - - · 336 views

The particle system is moving forward; I've fixed various update, clean up and spawning errors in the last few weeks.

I've also integrated the C++0x/TR1 random number generators and after a bit of a play I've decided I probably need to make those 'plugable' as well as you can get some intresting effects just by varying the system used to return the random numbers.

But, all in all, its starting to look more like a proper particle system now which is nice, although there are a few odd things (flicking dead particles?) and a crash in the thread dispatch stuff which I've seen happen twice now but I've just not got around to debugging yet.

It also occured to me the other day that I should really be setting up my threads to use batches of particles which were multiples of cache lines long on the system its executing on to prevent issues with cache line invalidation across cores.

Anyway more later when I've these issues sorted out and I can supply screen shots or maybe even a demo.

The other thing to happen of late is that on tuesday I was given my 6 week notice where I work, so my final day there will be July 6th and the lack of cash in the future aside I'm ok with it.. in fact I'm kinda happy.
(I'd also been expecting this for about four weeks so it was no shock)

You see, it occured to me that for the last two and a half years I've not been doing the 'right' job. Sure, I can do general programming but my talents are really in the areas of software design/architectre at both the high and low levels, graphics and a large body of knowledge with multiple threads and task based systems (which I admit is still developing but an area I'm still better than many many people at).

What I've been doing it general coding and pish like 'setting up build machines' and running around fixing bugs mostly caused by other people.

In fact, its recently dawned on me that I've simply not been happy here for the last 6 months at least; don't get me wrong the people are great but the work and the company itself leave a lot to be desired.

Also, looking at some of the people they decided to keep over me... well, I'm kinda glad I'm heading out the door; the same day I got told I was being let go he was having trouble applying an operator to sort a vector of pointers.

So, yeah, looking around those who are left, while they can do the job I'm pretty sure I'm far more skilled than many of them in plenty of areas (such as system design if the project I was working on before my recent two was anything to go by... those in #gamedev probably remember my swearing about that design..).

While many people would take a knock to the confidence and the ego when being let go I've gone a different way by looking around and going "riiiiiiiight...".

I think I'm better off out of there even if it does mean in a few months time I'm having myself declared bankrupt as I've got no income *chuckles*

Roll on July 6th...

More Particles

Posted by , 27 April 2010 - - - - - - · 231 views

I spent a bit of the weekend, between Civ4 sessions and starting a reply of COD4:MW, working on getting a renderer hooked up to the particle system.

The practicle upshot of this was that I had to finish off said particle system and the logic to make it run... ok, so it still doesn't render (I'll be PIXing the hell out of it wednesday evening to figure out why) however it is now hooked up.

So, the setup is pretty simple;

Shard::colourModifierCollection colourMods;
Shard::positionModifierCollection positionMods;
Shard::rotationModifierCollection rotationMods;
Shard::DefaultColour defaultColour = { 1.0f, 1.0f, 1.0f, 1.0f};
// life time in milliseconds therefore 16.6 * 60 = 1 second due to 16ms time steps in hardcoded use
Shard::EmitterDetails emitterDetails(5000,50,(16.6f*60.0f), 0.05f, defaultColour, 1.0f, positionMods, colourMods, rotationMods);
Shard::ParticleEmitter emitter(emitterDetails);
Scheduler particleScheduler;

An emitter can have modifiers for colour, position and rotation factors, these are basically std::vectors of function objects which take a few parameters, most of which are structures wrapping references to _m128 type variables due to the SSE underpinnings of the system.

EmitterDetails is a structure which holds information describing an emitter; the idea behind this was that you could construct such a thing in a script and then throw it at the particle system to build your emitter.

Finally the emitter itself is constructed using these emitterDetails; it makes a local copy so one details block can be used to setup multiple emitters.

The last object created in that list is a Scheduler object which is used to allow the queuing of functions to run.

As you might recall from the last update I was debating how to deal with block updating the particle system to spread the load over threads.

In the end I settled for supplying a ISchedular interface which had a simple function to queue tasks.

struct IScheduler
virtual void ProcessTaskQueue(float) = 0;
virtual void QueueTask(const UpdateFuncType &updateFunc) = 0;

In this instance its a very simple class indeed;

struct Scheduler : public IScheduler
Concurrency::task_group group;
Concurrency::concurrent_vector<UpdateFuncType> taskVector;



void ProcessTaskQueue(float time)

std::for_each(taskVector.begin(), taskVector.end(), [this,time](UpdateFuncType &task)
this->group.run(std::bind(task, time));

void QueueTask(const UpdateFuncType &updateFunc)


Each task is queued into a vector then, at a later point, a single thread will call the process function which will, in this instance, tell a Concurrency Runtime task group to execute the tasks. We then empty the task queue and wait for them to finish before moving on.

All of which has changed Emitter's PreUpdate function to

void ParticleEmitter::PreUpdate(IScheduler &taskQueue, float deltaTime)
// Services any required trigger calls
const EmitterPosition & position = queuedTriggers.front();
if(details.maxParticleCount > usedParticles)
usedParticles += EmitParticles(position);

// then work out block sizes and schedule those blocks for updates
//TODO: figure out what kind of task interface this is going to use
if(usedParticles > 0 && usedParticles <= 500)
taskQueue.QueueTask(std::bind(&ParticleEmitter::Update, this, _1, 0, usedParticles));
int total = usedParticles;
int start = 0;
while(total > 0)
int size = (start + 500 > usedParticles) ? usedParticles - start : 500;
taskQueue.QueueTask(std::bind(&ParticleEmitter::Update, this, _1, start, start + size));
total -= size;
start += size;

The numbers used for division of work are pretty random right now; I'm considering doing something based on cache line size instead to try and improve the work load. This would have a natural knock on to the update functions as well which could probably be changed to do some prefetch work, certainly in the case of the larger update function segments.

Finally, the usage of the Emitter is pretty simple. First we grab a trigger point (technically optional but its a good test)

if(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
if(msg.message == WM_LBUTTONUP)
int xPos = GET_X_LPARAM(msg.lParam);
int yPos = GET_Y_LPARAM(msg.lParam);
emitter.Trigger(xPos, yPos);

Then, in the update loop (which is currently fixed time step) we do the following;


And finally rendering is currently done via the deferred context system (which I need to change in order to PIX it later...);

RendererCommand particlePreRendercmd = DeferredWrapper(std::bind(&Shard::ParticleEmitter::PreRender, emitter, _1 ), g_pDeferredContext, width, height);
RendererCommand particleRendercmd = DeferredWrapper(std::bind(&Shard::ParticleEmitter::Render, emitter, _1 ), g_pDeferredContext, width, height);

Concurrency::send(commandList, particlePreRendercmd);
Concurrency::send(commandList, particleRendercmd);

And there you have it, a hooked up, if not yet rendering, particle system.

The next job will be, as I mentioned, to get it rendering so hopefully next update will have some (unimpressive at first I dare say) images to go with it.

After that I'll try to get some decent effects going and figure out how I'm going to video it in action.
And, as I discovered, I'm also going to need a 'material' and 'renderable' system at some point as my Emitter has an annoying amount of D3D11 stuff directly in it.

Well, until next time...

Recent Entries

Recent Comments