A quick note:
I appologize for the long post. I’ve spent the last couple of hours reading various threads. I’m not trying to start or contribute to a MDX or COM bash fest. I’m looking for SOLID comments from people that have tackled, or are struggling with a similar decision I’m facing now.
I’ve spent the last 2 months working on specs for my company’s next generation graphics system. In general, our new graphics system will operate as a 3D graphics engine. This engine will spit out frames to a TV output board that needs a constant 30 fps frame rate. Some of the content will be pre-rendered to movie files, and the rest will be output in real-time.
< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
At first, I was planning on using C# and MDX. Unfortunately, we’re stuck using a hardware specific SDK that uses COM. So I’ve been struggling with the decision of switching from MDX to the unmanaged/COM API for DirectX.
The reason I’m struggling with this decision, is because I’d prefer to due the bulk of our development using the .net framework. I’m having trouble trying to decide where to draw the line between COM and the .net framework for our new system.
There are a few reasons why I’m considering the unmanaged/COM API for DirectX.
1. Marshalling data in some instances between COM and .net can be costly.
2. The MDX API appears to lag in its development timeline from the COM API.
Reason for #1:
I’ve read a great deal about passing objects between managed and unmanaged code. Specifically between COM and the .net framework. It sounds like CCW and RCW can be costly and leads to duplication of objects in managed and unmanaged memory. Our software will be in some instances moving HD size frames across the system bus to our TV output card. Obeying our 30 fps limitation at a HD frame resolution will be challenging enough, without having to worry about crossing these boundaries.
Reason for #2:
I attended the Microsoft Meltdown conference in 2005. It was great meeting the DX community. The sneak peak of DX10, and the next generation Shader technology was incredible. However, someone spoke up during the DX10 lecture, and asked when the MDX API would be available in conjunction with the launch of DX10. No one on the DX team that was present in that lecture could answer this question. Someone simply stated it would “probably” be a release or two after the original SDK was available for DX10. This bothered me greatly at the time, and still does. This says to me MDX is considered an afterthought by Microsoft. This may not be a fair assessment, but it does concern me.
I hope I didn’t offend any MDX people. I love C# and MDX. When I first started down the road of MDX, I bought Tom Miller’s MDX9 kickstart book. The book was great, and it hurled me into a new world of programming that I enjoy. I’m just wondering if my particular application of DirectX would be better served by moving to the COM API.
MDX or not MDX! That is the question...
Tony Lambert
From what I have dealt with with c#, I would definately not change over to COM. As you said, nor do I want to start a COM/MDX flamewar but with C# you can concentrate more on whats important and less on what pointer goes were.
Though on the other hand you did state that you were working on a next generation engine so in all fairness, what pointer goes where might be important.
I know that you said that you would have to use that hardware specific api, but I still say if there is any possible way to stick with MDX, it will make your work easier and faster.
Regards, Mike
Mutantodon
WesHoward
Something you shouldn't overlook: garbage collection. Garbage collection is noticeable when something is animated on screen. You won't be able to meet your 30 frames per second requirement when that happens.
In my application, the GC is triggered about every second, when the application is idle waiting for the vertical blank.
Of course, that has nothing to do with MDX, it has to do with using .NET in the first place.
Khin
An interesting (if frustrating) dilema
I'll admit up-front that I'm not much of an MDX programmer, but I originally started DirectX via the unofficial (and later official) VB6 type libraries - which, I suppose, could be considered as the first "non-native" DirectX interface...
It had a number of similar problems - the extra interop/communication added extra overhead that made it difficult at times to squeeze all of the available power out of the hardware. A number of my projects resorted to DLL magic to get the best of both worlds.
I wonder if the same might work here - I don't know enough about your application, but could be possible to architect it so that you have your "business logic" and application code in C#/.Net and then have the low-level powerhouse code running entirely natively
The logic being that the expensive part is crossing the boundary between .Net/COM, so you design your application to avoid crossing that boundary wherever possible.
It's only really possible if you can somehow seperate the data so that the C# code doesn't have to directly access the raw data. For example, I had a C++ DLL that did a number of per-pixel operations on a DirectDraw surface, and the processing of that much data was simply not possible in VB6 - so I offloaded *all* of the calculations to an optimized DLL and then had VB6 just issue commands to it and let it deal with the processing. The DLL owned the data and performed the operations, but VB6 controlled how and when these operations occured.
Another trick I've seen used to great effect in video output is that of worker threads and output queues. Again, it's quite application-sensitive, but you can buffer a number of frames and make the processing parallel in order to hide the data copying/processing latencies.
hth
Jack
sjw7
PS: You didn't offend me and i'm a loving MDX programmer (I think).
I hope this helps buddy.
Take care.
snakegamer
Thanks for responding to my post everyone. It sounds like I need to decide where to draw the line in the sand between COM and .NET.