Archived

This topic is now archived and is closed to further replies.

DX9 .Net Framework Docs == Garbage

This topic is 5215 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Does anyone have any idea when MS is actually going to complete (hell, even starting it would be good) the DX9 .Net Framework Docs? What they have there now is absolute garbage and there''s really no excuse for it - they''ve been planning DirectX on .Net for years. Not all of the MDX functions are analogous to their C++ counterparts. Some of them are just downright convoluted. Not even Google knows what the hell I''m supposed to do with a GraphicsStream. I know, I know, it''s not intended to be a serious tool, but come on! If you''re going to do something, do it right. Sorry, that was just a rant.

Share this post


Link to post
Share on other sites
You''re right, and I''ll apologize for us upfront about the state of the docs. However, the choice was to ship MDX when we did, or put it on the shelf until docs were completed. I think we made the right (although potentially frustrating) choice to ship it with less than ideal docs.

The docs are improved in the current DirectX SDK beta, and we will continue to improve them as we release future versions of the DirectX SDK.

If you have specific feedback, please pass it along

thanks



Development Lead, DirectX
Windows Graphics & Gaming Technology

Share this post


Link to post
Share on other sites
I just wish it was easier to use the docs without having VS .Net. Instead I have to jump through several hoops before I can get the documentation registered with the system. Which is a pain to do after every SDK update.

Share this post


Link to post
Share on other sites
FWIW, here''s what I know about GraphicsStream (or what I remember, as it''s been a while since I''ve done MDX).

GraphicsStream is an alternative way to work with resource data (vertex, texture, etc.) -- you can choose to get back a managed array or a GraphicsStream. The problem with the array option is that the data has to be copied to and/or from the managed array. In principle GraphicsStream lets you work with the data more directly because it basically just encapsulates the raw pointer.

So as you might imagine, locking to get back an array is slow and locking to get a GraphicsStream is fast. However, last time I worked with this stuff (DX 9.0), the way GraphicsStream is implemented leaves a lot to be desired. It''s fast to lock but accessing individual elements of the data is ridiculously slow. When you write a float to a vertex buffer, for instance, a function is called internally that''s sort of like memcpy (except that memcpy would be faster). Ouch.

I don''t know if this has improved yet. I hope it does. But if performance is a concern you might be better off resorting to unsafe code, getting the raw pointer via GraphicsStream.InternalData.

Share this post


Link to post
Share on other sites
I agree that it is very frustrating spending hours and hours and hours doing something that would take 10 minutes if there was ANY sort of documentation. It is pretty bad the way it is...

Here is a Wiki that has directX links and it is a WIki so you can add any other that you find.

http://www.seedwiki.com/page.cfm?doc=DirectxLinks&wikiid=2492&wpid=0




Of all the things that I have lost, it is my mind that I miss the most!

Share this post


Link to post
Share on other sites
quote:
Original post by Donavon Keithley
I don''t know if this has improved yet. I hope it does. But if performance is a concern you might be better off resorting to unsafe code, getting the raw pointer via GraphicsStream.InternalData.


The InternalData pointer method is nice and fast BUT I have found a few problems with it. Do not use the InternalData pointer unless you have a STATIC vertex buffer. The pointer the method returned works great the first time, but if you lock the vertex buffer using the DISCARD flag the InternalData pointer points to the !!OLD!! vertex buffer, not the new one. By using this old pointer you are writting over the old vertex values which leads to some pretty nasty visual artifacts I guess when the docs say we shouldnt use it, they knew something we didn''t

I do not know of a work around. Using arrays is slow but I do not think we have a choice

Share this post


Link to post
Share on other sites
Well, it''s good to know that it''s at least being worked on.

From a technology adoption point of view, I think it would have been better to release a complete SDK instead of something that works, but is either difficult to use or weak in its implementation. A stimga like that can brand a technology for life. DirectPlay, for example, didn''t support IOCP when it first came out, and thus got a reputation for being worthless and slow. Only now are people beginning to give it a second look, but most of the damage is already done.

Share this post


Link to post
Share on other sites
I for one am one of the programmers that wanted the MDX SDK released ASAP (with or without the docs).

I have been frustrated with the incomplete docs and examples, but I would rather have the SDK now instead of interop access only.

Tommyboy

Share this post


Link to post
Share on other sites