none
How does Direct X integrate with Win RT ?

    Question

  • Hi,

    Just to set the scene, I've been using SlimDX for accessing Direct X 11 in C#. But I'm very much interested in how Direct X 11.1 will be made available to C# and how I can work with C#/DX11.1 on the Windows Store platform specifically. Obviously there is SharpDX. But at the moment I'm just trying to understand how interop might best work on Win RT to connect Direct X with C#. And how I might implement such interop, or at least understand it better.

    So I've read or heard via the build videos that Direct X has been integrated with WinRT, at least, that's what some of the diagram's portray. But when I inspect the WinMetadata folder, Direct X is not part of the WinRT object model (it seems to me).

    So is it that Direct X is in WinRT by name only ? And has it not been functionally integrated ? I would imagine that if it were integrated, then the CLR could generate a Runtime Callable Wrapper as needed, but performance might not be as good as say SharpDX. I'm not sure if SharpDX uses C++/CLI or C++/CX.

    And if interop between Direct X and C# were implemented for RT, what then would be the best way. I would say use class libraries rather than Windows RT Components as I am only interested in C#.

    Also, I would say use C++/CX rather than C++/CLI as I believe that CX provides better interop performance. In fact CX might be the only way to write RT wrappers (but this is confusing because as I've said, Direct X might not be actually a part of RT even though it is shown to be) I haven't quite worked out how CX fits into the picture other than to say it's next gen C++/CLI and is CLI for RT. So I would use CX to provide Direct X with a managed programming surface ? Or C++/CLI otherwise

    Am I starting to understand this properly ? Or what can be said about how to approach this problem ?

    Tuesday, November 20, 2012 12:37 AM

Answers

  • There are several questions in your post, making it a bit confusing. Let me try to reformulate this: What are the options, pros and cons about accessing DirectX from a C# Windows Store App?

    As you have discovered and It has been said here, DirectX is a low level COM api that doesn't have any WinRT component. So in order to have access to DirectX from a C# Windows Store App, you need a DirectX Wrapper:

    • You can develop a .NET wrapper: SharpDX is for example doing this efficiently by using a custom and fast interop layer (it is not using the standard p/invoke), statically generated from DirectX C++ headers. It is using some special IL bytecode instructions that are usually only accessible from C++/CLI to perform this interop. This is a fine grained API: almost every method/function in C++ as a straight equivalent in SharpDX. Because the API is generated from C++ headers, the marshal code is consistent and very efficient. It is handling all COM errors automatically, throwing an exception whenever a COM method/function failed. Also, It is adding typed objects that are not always available in the C++ headers: some part of the DirectX API are taking UINT enum flags so you need to look at the documentation to know which #define can be used for this particular method. So it is a bit less low level than pure DirectX, but it is still a low level API compare to say XNA. You can use the same API from Desktop, Windows RT and WP8. Developing yet another DirectX .NET wrapper would be quite a waste of time imho (SharpDX was developed two years ago to solve lots of issues with SlimDX: no AnyCPU, code handwritten, marshal not consistent, no individual assemblies, C++/CLI not obfuscatable/mergeable...etc.)
    • You can develop a C++ WinRT wrapper. Writing a WinRT wrapper implies that this wrapper would be only available from a Windows RT or WP8 API. You would not be able to use this wrapper from C# Desktop. The good thing is that a WinRT component is accessible not only from .NET but from JS as well. Also because WinRT doesn't expose pointers and DirectX is exposing mostly pointers, you will have to wrap every single API with a WinRT Platform type. Then, to write this WinRT component, you would have two options
      1. Write a high level DirectX WinRT wrapper, acting as a XNA like API: That would be probably the best option if you are trying to build a WinRT wrapper. You have fewer calls to map, you can handle all the complex DirectX things directly into C++. Downside is that, well, it is C++ and if you are not familiar with it, It is *way* much more tricky and cumbersome to manage for a casual developer than using C#.
      2. Write a low level DirectX WinRT wrapper acting as a DirectX WinRT API. This kind of wrapper would be better handled automatically (like SharpDX code gen) rather than doing it manually (as this is done with SlimDX). SharpDX code generator could have even been adapted to generate such a layer, but It was done not for several reasons: this wrapper would be locked to WinRT while a pure .NET wrapper is able to run on desktop as well, no AnyCPU,  compilation time (welcome to C++ world, even if you are using pch), Structs/value types used for example to provide a math api (Vector3, Matrix...etc.) would be inefficiently mapped into WinRT (no inline methods). Also, performance wise, I have not tested, but I don't know if WinRT interop is efficient (but it could be not, as regular p/invoke).

    Alexandre Mutel - SharpDX - NShader - Code4k





    Tuesday, November 20, 2012 12:45 PM

All replies

  • So the problem is that DX swap chain controls aren't available directly to managed apps, if I understand correctly.  You can't use the window as a render target.  You might be able to use a bitmap as a render target and just swap out the bitmap every frame, but I think that is as much as you can do without going fully native.


    KeepMyIdentities, Your Key to Password Security. Available now on the Windows Store: http://apps.microsoft.com/webpdp/en-US/app/keepmyidentities/61a9f340-97ac-4666-beab-39f9246cb6fa

    Tuesday, November 20, 2012 3:21 AM
  • @InLocoAbsentia - What I'm interested in doing is understanding how I might implement a wrapper like SlimDX and SharpDX around Direct X, limited to the Windows RT platform. SlimDX actually works very well for me on desktop, I don't know if you are familiar with these libraries, but they do in fact provide full implementations of Direct X for C#, SlimDX is only for desktop, while SharpDX goes further to provide DX11.1 and Windows Store App support.

    These libraries provide fantastic performance. So you absolutely don't have to touch C++ in order to get the power of DirectX. Well you won't get the full performance benefits, but it's pretty darn good. I'd say second to Direct X itself.

    I suppose the best thing I can do is get some versioning software and take a look at the source for these projects. And see if I can translate that into Cx. I've looked at the CLI code that SlimDX uses, but I have no idea about SharpDX and how it's done there, I know they have different implementations.

    Tuesday, November 20, 2012 4:35 AM
  • DirectX is not exposed as WinRT objects. Its only COM (that's the gap SharpDX tries to fill).

    /Morten
    twitter: http://www.twitter.com/dotMorten
    blog: http://www.sharpgis.net

    Tuesday, November 20, 2012 5:36 AM
  • There are several questions in your post, making it a bit confusing. Let me try to reformulate this: What are the options, pros and cons about accessing DirectX from a C# Windows Store App?

    As you have discovered and It has been said here, DirectX is a low level COM api that doesn't have any WinRT component. So in order to have access to DirectX from a C# Windows Store App, you need a DirectX Wrapper:

    • You can develop a .NET wrapper: SharpDX is for example doing this efficiently by using a custom and fast interop layer (it is not using the standard p/invoke), statically generated from DirectX C++ headers. It is using some special IL bytecode instructions that are usually only accessible from C++/CLI to perform this interop. This is a fine grained API: almost every method/function in C++ as a straight equivalent in SharpDX. Because the API is generated from C++ headers, the marshal code is consistent and very efficient. It is handling all COM errors automatically, throwing an exception whenever a COM method/function failed. Also, It is adding typed objects that are not always available in the C++ headers: some part of the DirectX API are taking UINT enum flags so you need to look at the documentation to know which #define can be used for this particular method. So it is a bit less low level than pure DirectX, but it is still a low level API compare to say XNA. You can use the same API from Desktop, Windows RT and WP8. Developing yet another DirectX .NET wrapper would be quite a waste of time imho (SharpDX was developed two years ago to solve lots of issues with SlimDX: no AnyCPU, code handwritten, marshal not consistent, no individual assemblies, C++/CLI not obfuscatable/mergeable...etc.)
    • You can develop a C++ WinRT wrapper. Writing a WinRT wrapper implies that this wrapper would be only available from a Windows RT or WP8 API. You would not be able to use this wrapper from C# Desktop. The good thing is that a WinRT component is accessible not only from .NET but from JS as well. Also because WinRT doesn't expose pointers and DirectX is exposing mostly pointers, you will have to wrap every single API with a WinRT Platform type. Then, to write this WinRT component, you would have two options
      1. Write a high level DirectX WinRT wrapper, acting as a XNA like API: That would be probably the best option if you are trying to build a WinRT wrapper. You have fewer calls to map, you can handle all the complex DirectX things directly into C++. Downside is that, well, it is C++ and if you are not familiar with it, It is *way* much more tricky and cumbersome to manage for a casual developer than using C#.
      2. Write a low level DirectX WinRT wrapper acting as a DirectX WinRT API. This kind of wrapper would be better handled automatically (like SharpDX code gen) rather than doing it manually (as this is done with SlimDX). SharpDX code generator could have even been adapted to generate such a layer, but It was done not for several reasons: this wrapper would be locked to WinRT while a pure .NET wrapper is able to run on desktop as well, no AnyCPU,  compilation time (welcome to C++ world, even if you are using pch), Structs/value types used for example to provide a math api (Vector3, Matrix...etc.) would be inefficiently mapped into WinRT (no inline methods). Also, performance wise, I have not tested, but I don't know if WinRT interop is efficient (but it could be not, as regular p/invoke).

    Alexandre Mutel - SharpDX - NShader - Code4k





    Tuesday, November 20, 2012 12:45 PM
  • @Alexandre - Thanks for the authoritative low-down. You've spelt out the considerations fairly well I think. At least I have a road map now. I'm not experienced with C++, so I'm looking into wrappers at the same time as learning C++ (I just got a C++11 book), which I understand is perhaps not the best way to go about things. But I'll see how I go. I'll be happy if I can build a minimal wrapper to allow device creation, shader compilation and some basic rendering. If I can achieve that I'll have learnt something. I suppose one way to approach this is to start with a high-level wrapper where I can focus on getting the C++/Direct X right and then break it down by parts as much as I'm able.


    Tuesday, November 20, 2012 2:17 PM