[quote name='Mauricio Cinelli' timestamp='1311613948' post='4840062']
But, C++/CLI is a whole another sintax compared to pure C++, and it would kind of act like a wrapper, but it will be like a "middle class" that interacts between the C++ code and C# code? am i right?
The syntax is basically the same, they just add a few extra symbols to allow the 'unmanaged' and 'managed' world to be bridged.
For example in C++ you have the pointer syntax Entity * for instances on the unmanaged heap, in C++/CLI this has been extended so that you have Entity ^ which is a pointer/handle to an object on the managed heap. Which you select depends on where the object exists and who needs to use it.
There is a bit of learning involved of course, but it's surprisingly simple and MS have done a good job with the language.
As for WinForms vs WPF that's very much a depends.
Last project I was on, all the GUI tools were WinForm based; this project they are WPF based.
WinForms are fast to throw together, however WPF does allow you to do more (such as skinning) but as to if you need it only you will know.
The only issues I know about regarding D3D and WPF is that WPF can only be used to draw to D3D10 textures, not D3D11. However this is only a problem if you intend to use WPF to render INSIDE your D3D app. I don't know of any issues when it comes to having D3D rendering to a control inside a WPF app, nor would I expect there to be any.
[/quote]
The issues that I saw related to D3D were from a earlier version of WPF and C# itself, i think it was 2 or 3, don't remember. So the problem using WPF with D3D in when i try to render using WPF? IF I have a GUI made in WPF that wraps, let's say, a game engine, I should have no problems? ( as long as the function calls are correct between C++ and C#)
Regarding the C++/CLI, I saw the ^ thing earlier and found it interesting though.