Hi all, so I've been trying to make a level editor using winforms and xna(A total pain in the arse btw) but Ive decided that when it comes to importing the levels into the game itself I'd like the game to utilise the full extent of DX11. This makes using xna quite pointless as any effect I choose to use in the editor would be restricted to dx9. So with this I would like to use DX11 in the editor but still need a good UI environment such as winforms or WPF. The only thing is I've never really mixed managed and unmanaged code before so that's new to me. I see WPF uses d3d to render and can be adapted simple enough but also hear it might be a dead technology and also would require me learning that from scratch. My current level editor is winforms so thought maybe I could switch out xna for a managed directx like slimDX? That way I could still utilise dx11 rendering and exporting would be easier into native dx11 game.

Basically I would just like any advice on which route to take, what your opinions are and preferably links to examples/tutorial/source code that could help.

Thanks in advance for any help.

Hi!

Hm, you would like to write your editor in C# and the game should be native? Sure, if you use SlimDX (which wraps native Dx quite well) for the rendering in the editor, porting should not be so hard, but it is much work anyway. You would more or less implement the whole rendering system twice… I think that’s not worth it, especially if you implement many fancy effects, you’ll always have to do it twice. Better don’t think about what will happen, if you see one day that you have to make changes to your rendering pipeline. Making only the game look nice isn’t a great choice either, since artists like to see in the editor what the game will look like in the end, right?

I guess, the best way to go, depends on what you would like to learn more about.

(a) If you want to create a game (focusing on game design stuff, trying out ideas by prototyping and so on) you should stick with C# (namely SlimDX) for both the game and the editor. This will definitely be faster than writing it with native code and you have more time to focus on the important stuff (achievements, punishment, feedback, replay value…)

(b) If you are more interested in the programming side, especially in architecture design that leverages the advantages of native code and can at the same time be embedded into winforms, e.g. for editors, you should consider writing your engine entirely in C++. Well, and then try to expose as little as possible by C++/CLI interfaces to the managed world (LoadAsset(), AddObject(), DestroyObject(), GetTransformOfObject(), …) and then just let your winform app reference the C++/CLI interface. This way you can use your native rendering system in managed code.

So, what do you intend to do / learn more about?

Greetings

Thanks for the quick and very helpful reply.

I guess I would prefer the B option. Ive worked with native directx before and is something id like to pick up again, also it would be more impressive as a portfolio piece. Also a good point that I wouldnt have to write the whole engine twice. My problem now is that I have no experience running native code in managed winforms, this whole c++/CLI thing is entirely new to me.

Do you have any resources or info as to how to render to winforms using directx?

P.S. I understand winforms have an aerospace problem with overlapping windows that MPF doesnt suffer from, is this a concern?

Hi,

I assume there are a dozen ways to setup native dx with C#. I can show you the way I did it in a project once.

In total we will need four projects. Two of them are on the “native side”, the other two are on the “managed side”.

• NativeEngineLib
  The renderer and all the usual engine stuff are written in a static library. Let’s assume we have one object called “Engine” in here, which encapsulates all the engine stuff. This library will be used on both sides; the actual game (native) and the editor (C#).
• NativeGame
  Your actual game (the exe) will simply link against the NativeEngineLib. In its main-function it creates an instance of the “Engine” and enters the main loop, calling Render(). Messages are passed to the "Engine". And that’s pretty much it.
• ManagedInterface
  In order to communicate with a C# program we need a C++/CLI dll, which links against the NativeEngineLib and wraps the “Engine” i.e. Init(HWND), Render() and MsgProc(). Now we have a managed class - let’s call it - “MEngine” that wraps the “Engine” and are now able to call things from a managed world.
• ManagedEditor
  This will be your editor. It references the ManagedInterface and declares a UserControl which initializes the MEngine and overrides OnPaint (->Render()) and DefWndProc (-> MsgProc()).

And that’s it. I wrote you a small sample project to help you setting this up.
[attachment=6302:NativeEngine_Sample.zip]
Good luck with your game!

Cheers

You sir are a gentleman and a scholar. The single most helpful person I've come across yet. This is exactly what I've been looking for and you've set me on the right track.

Thanks a lot.