QuakeLight Preview

Download this episode

Download Video

Description

In this video, I'm running a preview version of QuakeLight a Silverlight-based port of Quake.  Its very impressive to see an old-school classic game come to life in Silverlight 2.  Stunned, along with others, I interviewed Julien Frelat about the story behind QuakeLight, coding techniques used and when there will be a public release.

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      littleguru
      Nice. I hope we are going to see this in the wild Smiley Awesome work by Julien.
    • User profile image
      Bas
      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.
    • User profile image
      rhm
      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.
    • User profile image
      Koogle

      My interests in silverlight have just gone up! Smiley

    • User profile image
      Dan
      This is awesome Smiley
    • User profile image
      figuerres
      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....
    • User profile image
      rhm
      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.
    • User profile image
      tgrand
      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.
    • User profile image
      Bart Czernicki
      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.
    • User profile image
      Charles
      Incredible.
      C
    • User profile image
      staceyw
      Cool.  When do can we play?
    • User profile image
      magicalclick

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

    • User profile image
      ZroBug
      Can't wait to get an opportunity to review the code. Please show this as a live demo @ PDC 2008!
    • User profile image
      LightRider
      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...
    • User profile image
      AdamKinney
      The machine I used while shooting the video has a 3.0 GHz processor and 4GB of RAM.  That was also running on my secondary monitor as the primary monitor was displaying my script.  (Just kidding there was no script, just fumes from the permanent marker).
    • User profile image
      AdamKinney

      Are you going to be at PDC?  I could show it to you live if you wanted Smiley

    • User profile image
      Dodo
      How many cores? Smiley I'd be interested in the performance on a 1.6GHz single core, cause Silverlight is horribly slow there. Sad
      How many frames per second would you get? Tongue Out
    • User profile image
      AdamKinney
      Only one core, so if it scaled linearly, since I was getting around 55 fps, you would get around 29 fps.  But tha't probably over simplifying it quite a bit. Smiley
    • User profile image
      MagnumOpus
      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!
    • User profile image
      Pon
      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? Wink
    • User profile image
      Cream​Filling512

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

    • User profile image
      InnoveWare

      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.

    • User profile image
      Daniel Garzon

      Nice!!
      Impressive work!

      I feel nostalgic :_)

    • User profile image
      Izzmo
      Me too, this looks sweet.

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.