Indiefreaks wrote: I had a brief look at your code repository, and if both framework share the general objective to provide a higher level API, objectives are still significantly different, to name a few:

• SharpDX.Toolkit.Graphics doesn't target OpenGL API but instead is focusing on giving a full access to all Direct3D11 features without any compromise (including the most advanced one). Some features in DirectX are not always mappable in OpenGL (Computer shaders, separable depth stencil bufers and render target for the swap-chain ...etc.), or are a mess to map (some nifty details like z projection post vertex shader are between 0-1 in DirectX and -1 and 1 in OpenGL, samplers are no longer linked to texture in D3D11 unlike in OpenGL, stuff like that are really annoying to manage cleanly in a Framework).
• SharpDX.Toolkit.Graphics doesn't redefine math types already defined in SharpDX assembly. It is also leveraging on existing Direct3D11 API, so for example, when we instantiate a BlendState in Toolkit, we use the same description that we would use directly with SharpDX.Direct3D11. It means also that all Toolkit types are directly usable with existing SharpDX.Direct3D11 API.
• SharpDX.Toolkit.Graphics is currently only targeting "Graphics" and not input, audio...etc. "Graphics" API is the most complex one to map and the one that has most impact when developing a rendering application, while the others API can be quite localized in an application.

From a coverage point of view, SharpDX.Toolkit is already usable to create all available resources in Direct3D11 with specialized factories and to use them directly with Direct3D11 API. It is also providing methods to transfer data from the gpu to cpu and vice versa.

Also, performance wise, a method like DirectXGraphicsContext.Draw<T> in your framework is really inefficient and not recommended to use, as It is killing the perf to create/dispose a vertex buffer, upload it and draw it on every draw call.
Unfortunately, I really cannot do more than what I have described in this post. My spare time is very limited and entirely dedicated to support SharpDX, add new features, fix bugs, and respond to message in this forum (and I have a couple of other open source project to maintain, more sporadically, like [url=http://http://nshader.codeplex.com/]NShader[/url]). But you will be able to learn and get lots of information on how to implement a higher level API above SharpDX.Direct3D11 just by looking at the SharpDX.Toolkit.Graphics sourcecode (and periodically at future commits).

Hope this respond to your question.

RobJellinghaus wrote: ahah, if you need something next week, you should indeed better leverage on ANX. I forgot that they have perhaps a working SpriteBatch, so It is easier to start with it.

Your requirement is very simple, but in order to cover it, the Toolkit needs to have a proper Effect system and full texture loading. But if you want to do something quickly, you can already leverage on existing Direct3D11 API that are working on the desktop, and by using the legacy Effect framework and legacy texture loading (only available on desktop) It is fairly easy to develop a simple spritebatch implem, but if you are completely new to Direct3D11, It will take much more time than a couple of hours!

Great!!! I developed a HLSL material engine many years ago. I builded the shader dynamicly, based on materials and lights. It was very very easy, because you didn't know about HLSL, only materials. You could add new materials of course. It was made with MDX ( long time ago!!!)

I was using forward rendering, Point, spot and directional lights. ShadowMaps. You only needed to set the map in the material and the ShaderBuilder build the HLSL for you based on your material.

It was really easy!!!

It's interesting for you? I would like to help you building this great 'engine'

SharkDX wrote: Actually, I would like to keep the toolkit as nothing more than... a toolkit and not an engine.
At my work, we are developing an engine (on top of SharpDX for Windows desktop) and It is a huge and complex task if you want to do it well. SharpDX Toolkit is a much more modest project, It is just an enhanced graphics layer over the raw Direct3D11 API, but you could definitely build an engine on top of it, as one of the main objective is to expose all features of Direct3D11.

I've been keeping an eye on SharpDX for quite awhile and am very excited to see you're developing the toolkit layer!

As a background, I've been using GPU's for computation, with the added benefit of great graphics for display of the results. DirectX is preferable over CUDA since it is compatible with ATI and NVidia, as well as computation being compatible with graphics in a single hlsl language. And for us, .NET is the only way to go due to it's ease of use and breadth of features. I started with the easy to use XNA layer (GetData, SetData) in DirectX 9, but was forced to switch to SlimDX with DirectX11 and DirectCompute.

I've been wanting to switch to SharpDX ever since the beginning but have been waiting for your API layer that I know will be architected like no other. I've held off for now since I created a very rudimentary but useful API layer on SlimDX using extentions, and the availability of the .Tag field it provides on all it's classes to maintain the link between the CPU objects and the resources... certainly not ideal. I'm looking forward to get rid of all those extensions when your much more advanced toolkit becomes available.

One of the extensions, that may be part or your effects framework but I didn't see listed, was on the D3DCompiler. It would compile, using Generics, all the ComputeShaders, VertexShaders, PixelShaders, or GeometryShaders in an hlsl source file at once and return a Dictionary(of string, xxxxShader), with the key being the name of the function in the hlsl file (I used a rule to start hlsl function names by cs, vs, cs, and gs to make it easier to find what was what in the hlsl file). It would also save the compiled dictionary in binary format on disk, so the next time it wouldn't have to recompile (which could take >5 minutes due to the complexity of the calculations). For developing I also had an extension to recompile a single function in the hlsl, so at runtime most of the GPU code would be loaded from the binary, but edited functions could be recompiled quickly, replacing the dictionary item. Actually, looking at my code the shader compile is a regular generic function and the recompile is an extension on the generic dictionary.

All this is just a suggestion that managing the many shaders in binary form, with a method to recompile a single one from a source that may contain many others would be a nice feature in a toolkit.

As a side note, a method to determine how many groups a GPU can process in parallel would be great. It's probably there in some caps, but I haven't found it yet.

Thanks again for all your great work and website!

How will the Toolkit compare to XNA? I gather it will only cover graphics, but will it provide the same ease of use in that area? Do you have any plans to extend the API to cover other gaming needs - input, audio, etc?

pmertz wrote: Using a simili-Effect-Technique-Pass framework, you should not need to access independent shaders but you will get access to effects/techniques/passes, which will give you the same kind of features as having a dictionary of shaders names/shader bytecode.
Also note that because d3dcompiler is no longer supported at runtime on Windows 8 Metro, the effect framework in the toolkit will provide a runtime replacement.
pmertz wrote: I don't remmember there is such an information available from Direct3D11 API...

Dr_Asik wrote: Yes, mostly to cover graphics. It will provide the same level of features (+ all the d3d11 features) for all resource/states creations, graphics device/adapter, load-save textures/images, effect API... etc. Though there is no plan to integrate the mesh/skinning part (content pipeline conversion from X, fbx to intermediate formats...etc.).

This toolkit is mostly to ease the usage of D3D11 API and to bootstrap projects using D3D11 API.

For input/audio, there is no plan to provide higher level API than the actual low level API (XInput, XAudio2...etc.).