Managed DirectX

[xyz]

Hi,

There has been lots of talk about Longhorn and what it represents for future games, and it is also true that Microsoft is putting some effort on managed languages and managed directx...
My question: where do you think Managed DirectX will fit in the future and how it will be important for game development in MS future OS...

Thanks

[akira888]

The fact that any managed language running within .NET must be interpreted by the CLR virtual machine during run-time means that any application you code onto that platform will have much weaker performance than natively complied code. For that reason I don't see the .NET/Managed DirectX system (or any interpreted language) being the hot new platform for games anytime soon. Where I do see as potential is, for example, a in-store database application that displays data about products on the shelves now having robust and rich sound, imagery, even perhaps a 3D model for the customer to view that is relatively simple for the developer to implement.

.NET does have its advantages I must say. A simple text parser running in a window that used to take me days to code (just the interface) now takes me maybe an hour to draw the interface and code the operation and logical modules. I accessed Access :lol: and filled my tables from a remote database in about three hours whereas before stuff like that used to take weeks of trial and error.

"Managed" "Direct"X when you think about it is rather funny though... :lol:

[Remi]

Just a quick note to say that the CLR is a "bytecode to native code" compiler, and the developper can choose when the code is compiled - it can be done once for good during the installation for instance. The interesting part is that you can compile it with the optimizations options optimized for the processor on which the game will run, instead of just using blend optimizations as it is done today.

So from a performance point of view, the CLR isn't necesserally a bad thing...

[akira888]

Just a quick note to say that the CLR is a "bytecode to native code" compiler, and the developper can choose when the code is compiled - it can be done once for good during the installation for instance. The interesting part is that you can compile it with the optimizations options optimized for the processor on which the game will run, instead of just using blend optimizations as it is done today.

So from a performance point of view, the CLR isn't necesserally a bad thing...

Wow, didn't know that. The funny thing is that I just finished a (rather pointless) class in "software project management" that used C#.NET heavily and yet I wasn't aware that install-time compilation (instead of run-time interpretation) was an option. Each one of our assigned readings seemed to assume that <whatever language>.NET was interpret-only. :roll:

[NeARAZ]

Each one of our assigned readings seemed to assume that <whatever language>.NET was interpret-only. :roll:
All modern VMs (that includes .NET, Java etc.) have at least JIT-style compilation...

[Typedef Enum]

The fact that any managed language running within .NET must be interpreted by the CLR virtual machine during run-time means that any application you code onto that platform will have much weaker performance than natively complied code

This isn't exactly true. Once the JIT compiler generates optimized native code, it will run just like any other chunk of code/application. To say that it will have "much weaker performance" is not, IMHO, a true statement. There have been numerous tests done on this subject matter, and the conclusion is that it just depends...

I can't recall who did this...but it was linked on Slashdot about 2 months ago. Some outfit did a whole bunch of comparisons between Java, .NET, and native code. Under some situations (The one I recall was in the area of try/catch scenarios), .NET was a good bit slower...but there were a good number of others where the difference was fairly neglibible.