The Renderloop Re-Revisted...

Ah, the good ol' render loop.  Everyone's favorite topic of conversation.  As I'm sure everyone is aware, the Managed DirectX samples that shipped with the DirectX9 SDK as well as the Summer 2003 update used the 'dreaded' DoEvents() loop I speak so negatively about at times.  People also probably have realized my book used the 'infamous' Paint/Invalidate method.  I never really made any recomendations in the earlier posts about which way was better, and really, I don't plan on it now.  So why am I writing this now?!?!

If you read David's post about the upcoming 2004 Update, you may have noticed that he mentions the DoEvents() methods that samples used to employ is gone.  In all reality, along with the new sample framework, the samples themselves actually never use the Windows Forms classes anymore either.  The actual render window and render loop are all run through P/Invoke calls into win32, and I figured I'd take a quick minute to explain the reasoning behind it.

Obviously the idea of using DirectX is for game development.  Sure, there are plenty of other non-game development scenarios that DirectX is great for (data visualization, medical imaging, etc), but what drives our API are the game developers.  If you know any game developers (or are one yourself), you're probably vastly aware that while the game is running (and rendering), things need to happen quickly, and predictably.  With all the benefits of managed code, one thing that can be hard to achieve is that 'predictability', particularly when you're dealing with the garbage collector.

So let's say you decided to use Windows Forms for your rendering window, and you wanted to watch what the mouse was doing, so you hook the MouseMove event.  Aside from the 'cost' of the Invoke call to call into your handler, a managed object (the mouse event arguments) is created.  *Every* time.  Now, the garbage collector is quite efficient, and very speedy, so this alone could be easily handled.  The problem arises when your own 'short lived' objects get promoted to a new generation due to the extra collections these events are taking.  Generation 0 collections won't have any effect on your game, generation 2 collections on the other hand will.

Thus the new sample framework doesn't rely on these constructs at all.  This is probably one of the 'most efficient' rendering loop available in the managed space currently, but the code doesn't necessarily follow many of the constructs you see in the managed world.  So, when deciding on the method you want to use to drive your rendering, you need to ask yourself what's more important?  Performance, or conformance?  In the case of the updated sample framework, we've chosen performance.  Your situation may be different.

Comments

• Anonymous
  June 03, 2004
  Hi Tom,
  
  P/Invoking, to me at least, seems like a step backwards. While I understand the reasoning - performance - my personal feeling is that the reason for using Managed DirectX would presumably be the ease of use of the framework, rather than performance.
  
  My feeling is that the official samples from Microsoft should strive for conformance - not performance, because the samples are going to teach a lot of developers how to use DirectX.
  
  Is the point of the samples to demonstrate how to get started using Managed DirectX, or how to perform advanced optimization techniques?
  
  I think it will have an adverse effect on the .NET/DirectX effort.

• Anonymous
  June 03, 2004
  And what's the benefits of it anyway? I've created a full managed game with mdx and never had a problem with DoEvents (I used DirectInput for keyboard/mouse input). When you're having troubles with shortlived objects being promoted to gen1 it usually won't help eliminating DoEvents or other events. It's more likely it's design issue with your program like a huge number of boxing. Do you have at least any numbers that support the theory that this way is more performant?

• Anonymous
  June 04, 2004
  The idea of the sample framework is that you just dump it into your application and use it. The implementation (from a 'users' perspective) shouldn't matter, so long as it works and is fast. The new sample framework is both.
  
  Plus you definitely don't want the sample framework to potentially affect your code that's running, which could happen in the other scenarios (such as with the previous versions of the sample framework).

• Anonymous
  June 05, 2004
  The comment has been removed

• Anonymous
  June 05, 2004
  Of course you can.

• Anonymous
  June 06, 2004
  Can you give any clues as to when the 04' update will be made available?

• Anonymous
  June 10, 2004
  From my perspective, you definitely made the right decision by favoring performance. There are already lots of 'conformant' mdx examples and tutorials on the net. What is missing is more advanced functionality and real-life/production code examples.

• Anonymous
  June 10, 2004
  Is it possible to have a preview of this new RenderLoop ?

• Anonymous
  June 11, 2004
  The render loop gets switched.
  C# gets switched with version 2.
  DirectX gets switched with XNA.
  
  Here's one u can't answer:
  What's the future of MDX in relation to XNA?

• Anonymous
  July 31, 2004
  I am new to DirectX programming and I just bought your book (which is excellent by the way). Unfortunately, I already installed the Summer 2004 update and now I am receiving build errors whenever I try to compile the examples from your book. For instance, it appears the SetPosition method has been removed from the CustomVertex.TranformedColored class that is used in the Chapter 1 examples. What should I do? Should I uninstall the Summer 2004 SDK and go back to the Summer 2003 SDK instead? Any info or suggestions anybody can offer would be greatly appreciated.

• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=tom-miller-s-blog-the-renderloop-re-revisted

• Anonymous
  June 13, 2009
  PingBack from http://quickdietsite.info/story.php?id=12325