QuakeLight Preview

Amazing! Why isn't this somewhere more prominent, like the front page or something? If anything is an in-your-face demonstration of the power of Silverlight 2, this is it.

Edit: I guess it is on the front page. Didn't notice it before.

I'm looking forward to seeing how this is done. I mean obviously you can re-write the Quake software renderer in C# and have it write to a byte[] in place of video memory and with PCs being as fast as they are today compared with 1995, that will get you a decent fps at the resolutions demonstrated. No contoversy there. But what I don't get is how you get that byte array on screen in Silverlight 2, because I've been through all the API documentation and I just can't see a way other than turning each frame into a PNG and then having it decoded by the framework again and that surely wouldn't be fast enough.

My interests in silverlight have just gone up!

rhm:  in part i'd say the "secret" is that quake used Open GL and SIlverlight/ WPF has primitives that are in some ways like OGL ones.
I'd bet they had to make a kind of Maping from the quake engine calls that in turn called OGL to a C# classes that call the Silverlight / WPF bits.

not trivial but I bet it's not byte[] in most cases....

Quake had for example Textures as brushes on a surface to fill a triange/ mesh
Silverlight has an ImageBrush that can fill an enclosed path rect, triangle etc....

No, the author of Quakelight already stated that they are not doing that. They ported Quake's software renderer into C# like I said. I suppose people forget that games used to have software rendering engines. There won't be a Quakelight3 for example.

Unless there's some super-secret reasonable way of getting a bitmap onto the screen in Silverlight, I'm sure he's encoding each frame as a PNG.  It's not as bad as it could be if you make no effort to do the lossless compression, but there's still got to be some time wasted there.  I would love to know what % of time is spent on that piece.

I also wonder what machine he is getting this FPS on.  Furthermore, Silverlight does have some multithreading capabilities that I could see being used to speed up the rendering really well.

Maybe also he is using an optimized data structure.  For example, Analysis Services 2008 is using the probability based bloom structures for sets with NULL/Empty records.  Just by moving to this structure cubes with sparse data performa 20-30% faster. 

I wonder if something like that is going on where if it is doing simple png rendering with buffered rendering on other threads with some advanced probability data structures to figure out movement.

Cool.  When do can we play?

Nice nice, I hope more old school games ported to silverlight.

Can't wait to get an opportunity to review the code. Please show this as a live demo @ PDC 2008!

Obviously faked.

=P

Awesome post, this makes Silverlight look amazing in my opinion.

Wonder if this will draw John Carmack into developing for the platform...

How many cores?  I'd be interested in the performance on a 1.6GHz single core, cause Silverlight is horribly slow there. 
How many frames per second would you get?

This makes me want to jump in and try porting a console emulator to Silverlight / C#.
This is certainly one use of Silverlight MS never expected!

Good thing you're not using this as a demonstration of the speed of Sliverlight. 55fps on a 3ghz machine with a 12 year old game?

I wrote an SNES emulator in C# awhile back, trying to get it running as a Silverlight app.

Please note that the original Quake game was running by default in a 320x240 screen resolution and most critical parts were coded in highly optimized assembly code (John Carmack).

The demonstrated resolution here is 640x480 and is written in pure C#. The rendering part is as fast as possible given the current Silverlight limitations. Please note that no real optimizations were performed yet so this should improve soon.
Also we could benefit of dual core systems provided that we tweak the rendering to be multi-threaded.

In any case, on a same test case computer, the original assembly-optimized version is not running that fast with higher resolution. Of course, the OpenGL version outperforms everything with the help of hardware-accelerated 3D.

Nice!!
Impressive work!

I feel nostalgic :_)

Me too, this looks sweet.