[game] ragsmash

I just corrected the 'elastic band' problem in Ragdoll Smasher. This was due to a different handling of timers in XP and Vista.
This is now fixed!

[game] Ragsmash on YouTube

Someone posted a video of him playing Ragdoll Smasher on YouTube :-) watch it here

At least I know someone played the game ;-) It's really cool for a 'wannabe' game developer such as myself to discover this kind of things. Highly enjoyable.

A few explanations on the weird things happening that the player points out:
- guys stuck mid-air happen because the game only simulates 3 bodies. So it assumes others already landed. I could correct it ... but well, it's sort of fun.
- the 'elastic band' effect is more difficult. I have to look into it but it is likely due to instability in the stepping of the physics. Due to this, a very large force is produced. ODE is not able to propagate forces fast enough and one bone flies away while the rest of the body remains where it is.

Anyway, I am always happy to hear about ideas for a new version of Ragdoll smasher, so feel free to make suggestions. I had another stupid idea involving a chainsaw ... I played too much Doom I think ;-)

[C#] grabing pictures from a webcam

I have been looking for a simple way to grab a picture from a webcam, using C#. Well, it appears it is not so simple :-) The easiest solution I found is described here.

The code is simple, the only difficulty is to install the WIA sdk before (download from here, WIAAutSDK.zip). Don't forget to execute 'regsvr32 wiaaut.dll' in a command line, after copying the DLL in WINDOWS\system32.

WIA cannot be used for videos it seems. For this you'll need a DirectShow wrapper. (Note that the FTP is nicer in the sample code above).

And, if you just need to grab images and send them to an FTP, use Dorgem.

That was my 2 cents on webcams :-)

(I found Scott Hanselman's blog to be a great source of info on this)

[code] pure virtual function call

Calling a virtual method from a constructor is a very bad idea. Indeed, this can easily result in the 'pure virtual function call' runtime error. This is well explained here. Worse, if the method is not abstract it will call the method from the parent class, instead of calling the specialized one. It is worse because this will probably not directly trigger an error. Now, this 'issue' does in fact make sense: In the constructor of the parent class, the specialized class is not yet initialized. Hence, how could one of its method be called? Therefore, if you need to call a virtual method from a parent class constructor, you are probably facing a problem in your code design.

Nevertheless, I actually came accross an interesting variant of this issue, involving a thread. My parent class, A, is creating a thread in its constructor. The thread execution later involves calling a virtual method of A, which is of course meant to be implemented by inheritance.

The funny thing is that depending on 'how long it takes' before the thread calls the virtual method, we may - or may not - still be in the constructor of A. So, sometimes, this will produce the 'pure virtual call' error, sometimes not. Needless to say I was a bit puzzled the first time :-)
The solution was simply to implement a lock mechanism to make sure the thread calls the virtual method after the constructor executed.

[win32] Ascii, Unicode, Scan code, Virtual key

... and other keyboard nightmares :-)

I found two very useful functions in the Win32 API: ToUnicodeEx and ToAsciiEx. It converts from a virtual key code and a scan code to a unicode or ascii character. It can be used directly from a WM_KEYDOWN (or KEYUP) message.

Here is a quick code snippet:


uint scancode = (lParam >> 16) & 0xFF;
BYTE keyboardState[256];
GetKeyboardState(keyboardState);
char charvalue[2];
if (ToAsciiEx(wParam, scancode, keyboardState, (LPWORD)&charvalue[0], 0, GetKeyboardLayout(0)) == 1) {
  onKeyPressed(charvalue[0]);
}


Also check out this blog for more info.

[research] SIGcrash

Yet again, like so many others, our work has been rejected. It is not worth it. We won't talk about it. Ouch.

Submitting a paper to SIGGRAPH is a very emotional thing in fact. You put a lot of you in each paper. A lot of ideas. A lot of time. A lot of work. But here it is. It is rejected. Well, well, well. Sometimes it gets in, often not.

Anyway, you won't learn about the cool stuff we did ... but it should not bother you too much since our work was not above the threshold ...

Ouch. It is hard to keep a cold mind :-) Of course you'll learn about our stuff, we'll improve the paper and find a more friendly place for it!

Tonight I just want to have a special thought for all those who put so much in their work and will see it rejected from SIGGRAPH. As a reviewer, I am part of the whole reject / accept process. Giving fair scores is not an easy thing. I know deciding who gets in and who is rejected is not an easy thing for the committee either. But well, it still hurts.

[gpu] G80: The gritty details

Icare3D just released some in-depth tests on the G80 behaviour Read it here!.