.Net can be much easier to set up and get coding in, but if you are already familiar with c++, just stick with that a pure unmanaged DirectX.

Well, don't follow this if you're not comfortable, as this is just based on my own experience.

I got quite well at programming DirectX (D3D 8) in regular C++ code. I had implemented terrain, meshes, textures, and some other fairly simple applications using DX.

Now that I've bought Visual Studio .NET 2005 Pro, I started learning C# and C++ .NET. Now, I can easily create database-driven/more complex applications than I could with regular C++ and/or MFC.

I then downloaded the DX SDK (Feb. 2004 Release -- the last one to support Windows 2000 Pro). I started looking into MDX programming. And I also started looking into shader/FX development, which I never did before.

I got the hang of MDX/C# very quickly. There's not a lot to it. But you still don't want to jump into DX if you haven't done any C# yet. Just as you wouldn't want to get into pure DX before learning C++ and the Win32 API.

But I learned a lot of C# in a little amount of time. It doesn't take very long. At least not for me.

And just because I say it's easy, don't start getting into it. Make sure you find the same ease in using C#/MDX before you get really into it. I just wanted to help you decide what to do. I hope what I've said helps you. =)

Quote:Original post by jagguy
i still prefer just c++ clean code.

Use it then [smile]

I use C++/"native" DirectX simply out of choice rather than any fundamental reason why its better than the alternatives.

Quote:Original post by jagguy
ARe people though doing .net stuff because it's the thing to do nowdays?

There are always going to be people who jump on the technology bandwagon, but most people will weigh up the pro's/con's of each route and pick the one that bests suits them.

I started properly way back in VB6, had a run in with some C-like languages before that, but I loved VB6 because I could easily get to the "meat" of my projects and actually complete them. I wasn't spending days/weeks messing around with implementation details and frameworks/engines etc...

From what I've read, similar things seem to be true with .NET - you can get to the "meat" quicker and without less hassle from the implementation details.

hth
Jack