Quote:Original post by Mari_p
It 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.

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 :).