   Issues regarding MDX
  Hi,According to http://www.mdxinfo.com/: "The MDX platform is officially supported and endorsed by Microsoft and its performance is about 95% of normal (unmanaged) DirectX applications."It means MDX performance is 95% of Unmanaged DX independently of the code being written in Managed C++, C# or VB.NET, right?5% is almost insignificant... In this case, would it be correct to say that if you get 30 fps running an application developed with C++/DX, you would get around 28,5 fps if it were written in C#/MDX?Considering the productivity of .NET languages, will Unmanaged DX 'abandoned' in the future? It seems to use MDX be a tendency...Thanks in advance   
Quote:Original post by Mari_pIt means MDX performance is 95% of Unmanaged DX independently of the code being written in Managed C++, C# or VB.NET, right?That's what I gather from the quote. Keep in mind -- it's only an estimate.Quote:5% is almost insignificant... In this case, would it be correct to say that if you get 30 fps running an application developed with C++/DX, you would get around 28,5 fps if it were written in C#/MDX?That's very very generalized. Actual differences might be 0% in some cases, and more than 5% in others.The way I see it, using MDX would give you better productivity, so you'll be able to place optimizations in that would save back that "5%", that you might not have time to if you use unmanaged. This is obviously a personal issue, I'd bet many people feel they are more productive in unmanaged DX.All in all, you shouldn't care about this at all. Writing games isn't a contest. You won't get anything by running 5% or even 10% faster. Work on making the game fun, and find a platform that lets you do that easily.Quote:Considering the productivity of .NET languages, will Unmanaged DX 'abandoned' in the future? It seems to use MDX be a tendency...I don't see unmanaged DX going anywhere in the near future. On the other hand, that doesn't mean MDX won't become more popular.;Quote:Original post by sirobQuote:5% is almost insignificant... In this case, would it be correct to say that if you get 30 fps running an application developed with C++/DX, you would get around 28,5 fps if it were written in C#/MDX?That's very very generalized. Actual differences might be 0% in some cases, and more than 5% in others.Humm... I'm curious. Is there some specific case where MDX reveals a very bad performance compared to unmanaged DX?   ;  I can't remember for sure, but I think it usually has to do with certain types of low-level programming.  C# does some things brilliantly (even some low-level things), but there are other things that suffer from performance issues.  If I remember correctly, I don't think it's a really general case, it has more to do with doing very specific tasks.  I really I'm being very vague, but I can't for the life of me remember what those specific tasks were that it seemed to have performance problems with....However, should performance become a problem, you can throw some unmanaged C++ code right into your C# to handle the critical section more carefully.  The biggest issue there is that you have to handle your own memory (and thus, need to know what you are doing).I've also read some things about the garbage collector (GC).  Most of the time, the GC will have a negligible impact, but in some circumstances it can cause performance drains.  At the same time, it is (usually) a misunderstanding of how the GC works that causes the impact, so you can typically make it perform better by being a bit more careful.  See the book Game Engine Toolset Development for a fantastic chapter and more information.   ;  This really should be two seperate issues -- MDX and C#.When MDX was released, I remember the DX team stating a 3-5% slower number (I'm not sure what the exact number was, but it was something in that range). Now, this applies only to an MDX call, not to the whole application. A managed call to SetRenderState is likely to be somewhat slower than an unmanaged one -- but these calls take up very little CPU in general in most cases, so the difference really becomes irrelevent.As for C# -- theres been many threads about that, and theres no point in starting another. If you want to find out more about that, google it.All in all - I'd guess this doesn't matter at all since most indie apps are GPU limited. This means that even if you suffer a 10% reduction in CPU performance, you app wouldn't feel it, since the CPU would still be waiting for the GPU to finish its work.Hope this helps.   ;  A good example of where MDX would suffer a significant speed loss over unmanaged DX is if you were attempting to use the "WasStillDrawing" error that Present returns. If you set the DONOTWAIT flag, Present returns immediately after being called, and if it couldn't draw returns a "WasStillDrawing" error code. Now, in MDX, error codes are returned using exceptions, which are considered quite slow. If you'll be doing several calls to Present per frame until it manages to draw, you'll be wasting a lot of CPU time handling exceptions.Hope this helps :).   ;Quote:All in all, you shouldn't care about this at all. Writing games isn't a contest. You won't get anything by running 5% or even 10% faster. Work on making the game fun, and find a platform that lets you do that easily.Thanks :') Rating++, really, there's lots of people, me included unfortunately, that really liked/like the idea of MDX but still hesitate on whether or not or how slow/er it (actually) is, if at all. It took something as simple and logical as what you said to get me back at my senses, you've accomplished the so called dream of 'slapping through the internet'. Thanks :')Now I will no longer worry, and just MAKE game! This whole time I've been worrying about this when I in the first place don't even know a graphics API yet so I shouldn't have had to worry in the first place because I didn't know what the heck I was worrying about if there was a reason to. Besides, one thing I wasn't able to learn was that you could always just learn another API afterwards. Anyways, I'll stop thanking you and just rate you up.   