First of all, congratulations on the new Forum!
No matter how good a library is, a forum and the community it supports are invaluable.

Anyway, I'm a typical potential user of SharpDX:

I want to program in C#.
I'd love to make a game from scratch.
And I'm not so happy with the support XNA has anymore (or rather doesn't).

So... though I do understand tutorials are on the way,
maybe a few specific ones to help the transition from XNA to SharpDX wouldn't be a bad idea.

-Cheers

Not sure It will respond explicitly to your concerns but you can check the "SharpDX, where do I start?" post.

If you like to code XNA-like then you may be also interested in projects like MonoGame and or ANX.

sharpdx.org/about/related

Axiom is a classic. And DeltaEngine is coming along nicely.

I realize this is a somewhat stale post, but I tried to cover a high-level view of everything I had to modify/rebuild when moving from XNA to SharpDX in a recent blog post. I'd be happy to go into more detail if other XNA->SharpDX folks have questions...

Bryg wrote: Thanks Bryq, your blog post is indeed a good overview about the different part to encapsulate in order to achieve a simili-XNA framework.

With Direct3D11 and Win8 Metro, the challenge is becoming a bit more laborious to encapsulate:

• Direct3D11, because It has a huge load of features that need to be carefully handled and exposed by a framework in order to use it efficiently.
• Win8 Metro, because It is introducing several limitations, like the inability to use "Effects11" framework, correlated to the fact that you can't use D3DCompiler. So you basically have to rewrite a large part of an effect system (storing the metadata/bytecode in a file, managing efficiently the Apply() on the device...etc.), and this is again quite a significant work.

Luckily, SharpDX.Toolkit should cover this kind of problem, hopefully with a beta soon. Also, there are other options, like MonoGame Framework, or a much more advanced engine we are working at my work called Paradox (the website will open soon) that will deliver a full engine, and not only a plain graphics framework.

All true, I certainly didn't mean to sound authoritative on the subject, just sharing what worked for one guy. And trying to target a wider range of OS levels certainly puts more pressure on the coder. My priority list for the graphics portion of the engine was to support Win7 first, then WinXP, then 8.

Re Effects11: I actually wrap the Effect11 object in an engine-specific "RenderEffect" wrapper with its own parameter application methods and Apply() method, so if I wasn't being lazy (i.e. not trying to target Win8 yet) it would just be an issue of changing the internal implementation to handle the specific Shader bytecodes/signatures/constant registers. It could also stand to buffer pipeline changes so a state change could be compared against existing parameters and skip any redundant steps.

I'm definitely exited about the toolkit's progress (I think I mentioned that in the post, if not it's somewhere recent) though it was good practice to try and implement something myself in the meantime. I'm willing to bet the efficiency of the toolkit will beat out my solution

Can I ask what in particular about D3D11 you feel is troublesome? I just view it as a superset of features that you build a graphics interface from by choosing the subset that works specifically for your project.

And the Paradox engine looks amazing, great stuff!

Bryg wrote: Oh, your post is great as a return-on-experience, and oops, I hope too that my previous post was not giving the impression of an authoritative position!

Support things like WinXP is the kind of work I'm definitely not motivated to do, but glad to see that some people are still challenging this! From my little perspective, I hate so much the Direct3D9 API (mapping it in SharpDX was just a laborious job) and I love soo much Direct3D11 API that I would prefer to stay away from Direct3D9 (as well as OpenGL, but this is another story)!
Bryg wrote: Related to Direct3D11, Effects11, while still being a relatively a good framework is in fact not able to use efficiently Direct3D11 API. For example, It is not possible to share constant buffers between different effects, which can be problematic when you really want to control more closely constant buffers.
Bryg wrote: Oh, nothing troublesome. Just that all projects that are trying to bring a XNA API on top of D3D11 are going to limit a lot the features accessible (multithreading, geometry shaders, tesselations, compute shaders, indirect draw, structured buffer/unordered access...etc.). Though, I fully understand this from the perspective of targeting multiple platforms, specially when you have to deal with some devices with 9.1 feature level... But Direct3D11 is great to target device from 9.1 to 11.1 with the same subset API.
Bryg wrote: That's great to implement your own stuff. Lots of people are just complaining about the lack of XNA, and don't want to put their hand in the dirty details behind the scene, but It is absolutely worth to do it. It's also forcing the respect to some project like XNA (or some more advanced engine), when you look at all the code required to provide a simple and efficient graphics API!
Bryg wrote: Thanks!

xoofx wrote: I agree.

I believe it's time to go some steps further from XNA, but I recognize that one feature I will miss, to some extent, is the amount of file formats supported by the content pipeline out of the box.

I know just what you mean. I caught a lucky break with Assimp.NET handling model file parsing for me, but there are a lot of cases I haven't even addressed in my library (like audio...haven't touched sound at all).

Sorry for hijacking this thread, and going a bit OT.

The paradox engine does indeed look great. I'm really looking forward to learning more about it when it goes public. I guess we will learn about licensing and such when that happens.

These times begin to feel a bit like the start of a paradigm shift when it comes to game engines. A shift from native to managed code. Unity (sort of) started out by leveraging the .Net platform for game logics in a way that got a really good response from the indy community. Delta Engine Delta Engine and now Paradox are just two of the more recent efforts to bring .Net based engines to the masses. Of course there are others (RealmForge, Visual3D just to name a few). The trend now, however, seems to be to make the engines target multiple platforms and by that making them more attractive to game devs reaching a broader public. It seems more and more developers start to realize the gains from managed code outweighs the drawbacks. I hope this trend continues.

///JmD