Markus,

>> As far as Quake goes: Yes, that is a fairly straightforward story.
>> DirectX is available on the managed platform. This allows .NET developers
>> to send instructions straight to the graphics hardware. Performance
>> results are almost identical between native C++ DirectX and .NET DirectX.
>> Also, GPUs use a secondary language called "the shader language for the
>> programmable pipeline" or "HLSL". No matter what language you use to
>> communicate with the graphics hardware, shaders are always written either
>> in HLSL or in an assembler-like version of it. The shader is sent to the
>> GPU, and there is no performance difference worth mentioning, no matter
>> what language was used to send the shader to the card.

I would agree that in a lot of cases the .NET execution engine can equal/outperform C++. Its not difficult as the JITter has more scope for a more granular optimisation strategy, game development on the other hand is an area of software development that cannot be compared on a like-for-like basis unless you are algorithm's are implemented identically. For example, processor specific streaming instructions (MMX, SSE2), in C++ you can organise the instructions/data to fit into the L1 cache, with the JITter it only happens if Microsoft are doing it for you. Another set of problems are memory bandwidth, how are datatypes optimised? Big is not necasserally best and when you are dealing with large custom vertex formats then you don't want the compiler introducing optimisation bottlenecks.

One area I am very impressed with is generics and its implementation at the point of JITting.

As an aside all cards don't always support the full vertex/pixel shader specification, if they don't then they go through the reference renderer which is software based. Some support different texture passes, vertex shader counts etc. so having complete control over your environment giving you the ability to make pipeline specific decisions is where the managed world will hinder and not help.

Regards
Neil