Lost in the triangles moved! find it here: aras-p.info/blog

I saw Rag Doll Kung Fu website already a while ago. However, only today I saw the video of it's presentation at GDC. It's awesome! Will buy the game as soon as it appears on Steam (even if I don't play games).

Go to downloads section at the site and get this large video presentation. It's really good.

I've written down the basic idea here. Done some tests and it really seems to work!

That required tiny 700 lines of hacky C++ code in the engine; but in exchange there's no longer a need to write state restoring passes by hand. Maybe such effect usage scheme would even be useable in RealWorld!

Too bad I didn't think it up a couple of months ago. My ShaderX4 article about this subject would have been much better...

Ok, still got to test this stuff on real world data (i.e. trying it on our demos)

In my projects I've been using D3DX Effects with no device state saving/restoring. Instead, each effect contained a dummy "last pass" that restores "needed" state (see here; more lengthy article coming in ShaderX4).

I always wrote this "state restore" by hand. This is obviously very error-prone; it's ok if I'm the only one writing effects but would be unusable in any real world scenario.

I think I could automatically generate the "state restore" pass. Somehow the engine knows which states need to be restored; which must be set in every effect etc. (this could be read from some file). It first loads each effect file and examines what states it touches. This can be done by supplying a custom ID3DXEffectStateManager and "executing" the effect - the state manager then would remember all states (left-hand sides of state assignments) touched by the effect.

Then the engine generates the "state restore" pass and loads the effect again. I'd image it would do it like this: each effect has to contain a macro RESTORE_PASS:

technique Foo {
 pass P1 { ... }
 pass P2 { ... }
 RESTORE_PASS
}

Which would be empty during first load and which would expand to the generated restore pass on the second load (you can supply generated macro definitions when loading the effect). The engine can check whether the generated pass exists after second load (if it doesn't then RESTORE_PASS is missing from the effect - an error).

The downside of this scheme is that each effect file has to be loaded twice - first time for examining its state assignments and second time for actually loading it with the generated restore pass. It's not a problem for me, I guess, because effect loading doesn't take much time anyway... And if it would become really slow, all this stuff can be done as a preprocess (e.g. during a build).

There are many upsides of this scheme, I think: the whole system is robust and error-proof again (no longer depends on the effect writer to remember all the details about states). And as far as I can see, no performance would be lost at all (performance was the main point why I'm using this "restore pass").

Gotta go and implement all this!

Richard "legalize" Thomson (the organizer of Pilgrimage demoparty and DirectX MVP) just told me: he has done a 2-minute analysis of our demo engine dingus as a "wild demo". It took 3rd place in wild demo competition at Pilgrimage'05!

That is pretty funny. I never knew it has so much sourcecode inside! :)

Here I am coding various things and it suddenly struck me: C++ is pretty clunky. Now, I knew this to some extent for quite a time already, but the more I code C++ the more clunky it feels.

I admire it as a low-level language; it's very powerful and there's lots of unbelievable things you can do with it (think templates).

But still, it feels like a low-level one. I really want to code by "next project" (whatever that might be) in Lua, for example (especially now that LuaJIT is out).

The company I was working at for some three years, closed it's offices in Kaunas recently. Well, it was almost a year when both intera and motion parts of the name didn't already make any sense... At start we were doing computer vision, various game/graphics/entertainment stuff, but in the last year all development was about some computer networks management system. A couple of programmers will stay for some time to support existing systems, but afaik any new development is suspended.

I feel kinda sad, even if I blame the management for the failures mostly (we programmers never blame ourselves, you know :)). Yes, I/we could have worked harder, done better etc., but all the way I (and probably 'we') felt that the ambitions were too unrealistic^*, the business plans were too non-existant, the management was just a bit too poor, and some forward-thinking was 'just a bit missing'.

I guess that's just my attempt to transfer blame to someone else :)

That said, it's still sad. Oh well, just keep going on.

* Ambitions: "by that time Sony, Nintendo and Konami will be years behind us" doesn't sound very realistic, does it? :)