Tom Miller's Blog

The Ramblings of Miller. These postings are provided "AS IS" with no warranties, and confer no rights.

Features? Whidbey? Oh My!!

Features? Whidbey? Oh My!!

Rate This
  • Comments 48

Well, as I'm sure most of you are already aware, the Whidbey beta has been out for a while now, and hopefully some of you have gotten a chance to play with it.  Assuming you have, what features are you seeing that you absolutely love?  What features do you now find 'missing' when looking at the Managed DirectX libraries?

In short, now would be the perfect time to suggest features on things you might like to see in a "Whidbey" specific version of Managed DirectX.

( And yes, I'm aware of the loader lock problem using the current MDX assemblies with Whidbey.. So ignore that one.. :D )

Edit: Comments seem to be broken.. I'm trying to fix it.. Let me know if it works..

  • I think what I have come to realize over the years of using directx (since dx5 using patrice scribe's third party *.tlb files for vb) is that the documentation only describes what the individual Classes/methods of the dx api do. What the documentation does not do is tell you is how to best make use them.

    I personally am waiting for longhorn to ship to see what kind of performance gains it will have over GDI. I would love to just be able to use pure .net framework winodws forms code to create a game but it's way to slow for that.
  • I would like to see generics in all thier glory, especially when it comes to list and sorting. It would be nice to extend the refactoring/code snippets in VS2005 for common repetitive tasks in MDX.
  • For whidbey-specific features, debugging visualizers and generics top my list.

    A more general feature: Instead of using the generic "error in the application" message all the time, using the last few messages written to the debug console by DirectX would be awesome, so you don't have to turn on very slow unmanaged debugging to see them. They are usually quite accurate and informative when using the debug runtime. I guess it might be tough to access them from managed code, but perhaps the unmanaged guys could provide a hook for you to get at them? It would probably be the single best change you could make for improving beginners' experiences with MDX.
  • Though Debugger Visualizers have already been mentioned, I would like to say DebuggerDisplayAttribute is light and useful.

    Also, I'm interested in CLR 2.0 "reliability" features; SafeHandles, CriticalFinalizer and ConstrainedExecutionRegions.
    For example, it seems almost all P/Invoke Functions in CLR 2.0 have ReliabilityContractAttribute like this:
    ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)
    So I guess Microsoft BCL team has an internal guideline for the usage of Unmanaged Resources and if it is so I think it is reliable for the implementation of Managed DirectX.
    Anyway I hope Managed DirectX will be successfully integrated with the new .NET world.
  • I'm sure there's a ton that can be improved, as much as your book. However, focus on making 1.1 apps run smoothly with your 2.0 version. Last thing I want is Microsoft to again go crazy with their ideas breaking past software. Good luck.
  • By the way, please work on managed documentation before you start adding more features.
  • I have just install a game called Re-Volt and when I try to run it, the computer says no zbuffer. What could be the problem.
  • 1. VB Documentation
    2. The capabilties that exist(ed) in the now depricated DirectPlay.
    3. VB Documentation
    4. VB Samples
    5. VB Documentation
  • These have been mentioned, but I'll post here to second them.

    1. A Widget library
    2. More descriptive exceptions
  • This comment belongs attached to the last word on the render loop post, but commenting is dissabled for that post. I know you must be bored to death with the topic, but it is a *VERY* important one.

    Please include include the necessary code to implement this ultimate render loop in the official Microsoft assemblies as many developers (myself included) may wish to avoid any native methods in their code for security and potential portability concerns.

    One great addition to future versions of the managed libraries would be a replacement for Application.Run, such as Direct3dApplication.Run, which could implement this render loop by accepting an IDirect3dWindow which extends IWin32Window (or whatever it is) and provides a DoFrame method. At the very least, please include this render loop explanation in the documentation.
  • 1. Separate SDK for MDX wihout saples or documentation for unmanaged part :), smaller, lighter
    2. Shader visaliser with integrated editor would be nice
  • Design-time support! Please!

    TypeConverters would be extremely welcome for Matrix, Quaternion, Vector3, et al.

    You could look at the source for System.Drawing.Point and System.Drawing.PointConverter to see just how easy it would be to provide these TypeConverters.

  • PingBack from

  • PingBack from

  • PingBack from

Page 3 of 4 (48 items) 1234