Freigeben über


Now that the Whidbey Beta is out, what about Managed DirectX?

With the release of the Whidbey (err, I mean Visual Studio.NET 2005) beta a few weeks ago, my thoughts have drifted towards how Managed DirectX may work in this new release.  For those of you who haven't seen VS2005, or the new CLR, the changes there are magnificent.  Across the board, improvements have been made, and the thing is looking wonderful.

So my thoughts roll over to MDX, and I think to myself, “Self: wouldn't it be awesome if we took advantage of some of those features?”  Who wouldn't want to declare the vertex data they're about to use like:

VertexBuffer<PositionNormal> vb = null;
IndexBuffer<short> ib = null;

Of course that just scratches the surface of the possibilities that would lie in a VS2005 specific version of Managed DirectX.  Which begs the question, what do you think?

Comments

  • Anonymous
    July 12, 2004
    To quote many l337 (albeit immature) h4x0rz out there: that would "r0x0rz my s0x0rz". I would love to be able to initialize buffers that way. And of course, like you say, that only scratches the surface.

  • Anonymous
    July 12, 2004
    I would also add templates for primitives such as vectors and matrices.

  • Anonymous
    July 12, 2004
    What about when you don't know the vertex type at the time the VB is created? Or when you're packing meshes with different formats into a single VB?

    Maybe there's an opportunity here in templatizing GraphicsStream. or maybe some kind of typed IEnumerator. That might be interesting. But I haven't played around with generics yet so I don't what's possible and what isn't.

  • Anonymous
    July 12, 2004
    Naturally we'd want to do something like that.. The idea being anything that made sense using the new features (ie, vertex buffers, index buffers, textures, queries, graphics streams, etc) would do so..

  • Anonymous
    July 12, 2004
    Yes yes yes aaand yes! :-D

    By the way - are there any issues with MDX and the VS.NET beta? I am kind of itching to try it out.

  • Anonymous
    July 12, 2004
    Things are changing so fast with this...

  • Anonymous
    July 12, 2004
    That's a great idea for declaring vertex buffers. So, when are we going to get these kinda features (if ever)? DX10? I was also wondering if MDX works with the VS2005 beta? Has anybody even tried it out?

  • Anonymous
    July 12, 2004
    Would definitely like to see template usage. Esp. if it yields both programming simplification as well as performance improvements.

  • Anonymous
    July 13, 2004
    I would like to see generics in MDX, but please create a nested namespace for generic objects. Sometimes it is still handy to have general purpose objects.

    As far as I tested MDX in VS2005 beta things work ok.

  • Anonymous
    July 14, 2004
    Generic support would be nice, but I'd also like to see the Mesh helper classes create meshes with Basic texture coordinates (for easy crates!), and better Error messages !

  • Anonymous
    July 14, 2004
    Tom,

    It is a question of when not if:)

    yet's just hope that mdx can start a release schedule outside of dx. to get it to catch up. dx9 summer release probably one have it. so hopefully a MDX schedule to correspond to vs 2k5 rtm to take advantage of all of the new features.

    Generics of course I can see itenerators playing a huge part in several areas also.

    and possible partial classes with code generation for parts and code beside to flesh it out.

  • Anonymous
    July 15, 2004
    I think MDX should support generics in all possible ways.

  • Anonymous
    July 15, 2004
    I've tried out quite a large project on VS2005 and it imported perfectly and worked a charm. I was just testing though, I can't risk using the beta version (as much as I'd love to) for this project. So many things in Whidbey that I'd benefit from right now with the games programming side of things. Generics will speed up many otherwise costly Boxing/Unboxing procedures and null types would be VERY useful for some sitations i've encountered. Even without modifying MDX, Whidbey will benefit MDX developers greatly!

  • Anonymous
    July 16, 2004
    I a bit curious about how you guys do things at Microsoft. It seems like you don't talk to eachother. Doesnt someone enforce a consistent way of designing APIs? Sorry Tom, you shouldn't even be asking us about whether generics is the way to go for MDX. Someone at MS should have forced you to use it. As well as other design issues that makes all MS APIs become consistent. I love what you are doing for the ease of DirectX development, but I don't like how MS handles this.

  • Anonymous
    July 26, 2004
    I believe you misunderstand the point of the post. The post wasn't asking if the Managed DirectX API should have an API design that was consistent with the features of Whidbey, naturally any API designed to work and run under Whidbey should be consistent with the Whidbey API. We have API reviews, etc here to ensure that is the case.

    This post was asking about the potential to have a Managed DX API written for the Whidbey runtime instead of the 1.1 runtime it's designed for now. The question wasn't 'Should i use generics in this new API design', but rather 'Should we release a version of Managed DX designed to run on the new runtime' which inherently assumes consistent API design and includes features of the runtime.

    hth

  • Anonymous
    July 26, 2004
    The comment has been removed

  • Anonymous
    July 30, 2004
    How about managed DirectShow?!? I've read that it's not been done because the CLR isn't fast enough. But is the Whidby CLR fast enough?

  • Anonymous
    June 07, 2008
    With the release of the Whidbey (err, I mean Visual Studio.NET 2005) beta a few weeks ago, my thoughts have drifted towards how Managed DirectX may work in this new release. For those of you who haven't seen VS2005, or the new CLR, the changes there ar

  • Anonymous
    May 29, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=tom-miller-s-blog-now-that-the-whidbey-beta-is-out-what-about