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?

Published 12 July 04 01:49 by tmiller
Filed under:

Comments

# Jason Olson said on July 12, 2004 2:15 PM:
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.
# sk said on July 12, 2004 3:27 PM:
I would also add templates for primitives such as vectors and matrices.
# Donavon Keithley said on July 12, 2004 4:25 PM:
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.
# Tom Miller said on July 12, 2004 6:07 PM:
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..
# Micael Baerens said on July 12, 2004 11:19 PM:
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.
# xian said on July 13, 2004 5:25 AM:
Things are changing so fast with this...
# Darren said on July 13, 2004 6:24 AM:
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?
# David Weller said on July 13, 2004 6:31 AM:
Would definitely like to see template usage. Esp. if it yields both programming simplification as well as performance improvements.
# Kavan said on July 13, 2004 2:47 PM:
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.
# Russ C. said on July 14, 2004 8:15 AM:
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 !
# Douglas said on July 14, 2004 9:13 AM:
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.

# F176 said on July 15, 2004 8:54 AM:
I think MDX should support generics in all possible ways.
# Rick Hoskinson's Blog said on July 15, 2004 12:59 PM:
# Rick Hoskinson's Blog said on July 15, 2004 1:02 PM:
# Chris C. said on July 15, 2004 1:28 PM:
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!
# Managed Games said on July 16, 2004 2:12 AM:
# Björn Morén said on July 17, 2004 7:48 AM:
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.
# Tom Miller said on July 26, 2004 3:45 PM:
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
# Björn Morén said on July 27, 2004 5:35 AM:
Ok, then I misunderstood you. Sorry.

I thought the development of the 2.0 runtime was done in close contact with all major API design teams, so that all APIs would be brushed up, ready to take full advantage of new runtime features when VS 2005 was released. I was expecting such a MDX beta in the same timeframe as the VS 2005 beta, so we all could provide feedback about both the runtime and MDX interfaces and how they fit together. That would give both teams time to fix possible design flaws before all APIs get shipped.

I also realize that DirectX and the NET runtime arent necessarily in sync when it comes to releases. Peeking at Longhorn and what integral part DirectX Next plays in the OS, current DirectX ought to be as prioritised as Winforms and treated as a first class API even today. Which means high tie to VS 2005/2.0 runtime releases. What is MS plans for DirectX Next? Only a managed interface and a replacement for MDX?
# Thomas Fisher said on July 30, 2004 10:35 AM:
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?
# Relationship Compatibility said on June 8, 2008 7:04 AM:

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

# Tom Miller s Blog Now that the Whidbey Beta is out what about | Paid Surveys said on May 29, 2009 12:32 PM:

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

New Comments to this post are disabled
Page view tracker