Should I convert my graphic engine from C++ to C# using managed dx?

If you've already (significantly) completed the engine, no.

If you're starting afresh, and targeting the .NET runtime exclusively, yes.

Also, you should take into account performance considerations. With Managed DX, you have the added overhead of accessing DirectX through the wrapper classes and marshalling data between the CLR and native code boundaries. More importantly, however, your code will be executing within the CLR. The CLR is fast enough for most purposes, but it can't hold a candle the raw efficiency of a native-compiled C++ application.

Still, it is easier to code in C# (in my opinion), so it all depends on what you want to use it for.

Quote:Original post by nimrand
...The CLR is fast enough for most purposes, but it can't hold a candle the raw efficiency of a native-compiled C++ application.

Still, it is easier to code in C# (in my opinion), so it all depends on what you want to use it for.

95-98% is close enough that it shouldn't really make a difference. The framework's speed shouldn't be an issue unless you're trying to make Doom 4.

If you're doing it to make your engine more accessible, please do. Otherwise, I don't see the point.

I'm using C# and Managed DirectX because I don't know C++ but I do know C# so it's easier for me. C# is way easier to learn the C++.

As far as performance and graphics are concerned with games, the time to think about performance as at the beginning, at the middle and at the end, so C++ is the way to go, even for 5%.

When people say to use C++ over C# because of performance, I always shudder.

Let's say that C# is 85% of the performance of C++. In reality it is more like 90-95% depending upon the application.

So if your engine on C++ get 100FPS, then on C# it will be 85FPS (in general)... however, this will depend on whether your game is cpu dependent or gpu. If GPU, the performance of C# will be *very* close to C++. If not, then you will see the sample 85% noted.

The key here to realize that this is on a given hardware platform. How many weeks will it take before a new processor comes out and nullifies the original difference? Of course, the C++ version will always be faster, but *how* fast is enough?

If your C# version get 60FPS, and your C++ version gets 70FPS... well then it just isn't going to matter to the consumer much - and it won't matter to you either - except your massive productivity gains by using C#.

Now, if your engine is only turning 30FPS with C# and 40FPS with C++, well, maybe you have a point. But, again, by the time you are finished with your game, technology will have caught up once again.

Your game or engine isn't going to sell (or not) on a 15% (max) difference in FPS, it will be many other things.

C# offers so many productivity improvements over C++ there isn't time for me to list them. Others have listed the major points. I will note that Microsoft is moving towards managed code in LongHorn... and you will see much more cool stuff with WinFX, Avalon, etc. *and* tighter integration (meaning more performance) with the OS (no more wrappers).

If you like C++, there is nothing wrong with that. However, if you are writing for Windows, C# is the future. Look for the XBox soon to support WinFX :) (my prediction only - not from MS)

-Todd

Like the guy said above. If you're largely into (or near completing) your engine then don't bother converting. The only reason I would consider converting it to C++ is for compatibility issues. It seems that unless you're programming in C# most people dont have Managed DX installed and people bitch endlessly when you tell them they need to get it to be able to play your game -- I speak out of experience. Apparently a small download is too much hastle. So if you're going for accessibiliy you may have to convert (I'm looking to do the same once I get the engine done in C#)