xoofx

I'm not sure how easy it would be to interface with that API from C# though, as the SharpDX implementation looks incomplete.

It is not incomplete, the class is marked as "partial" so the other part of the code is generated at built time by the DirectX C++ to C# code generator used in SharpDX.

 

Edit: Though there are here some NotImplementedException for GetStorageFilter/GetRetrievalFilter, will have to double check

You will be able to see D3D11 messages directly from the output window if you check "Enable native code debugging" in the Project Properties/Debug tab (you need to use the debugger to see the messages) otherwise DebugView is still an option.

My apologize to wake up this old thread, but I ran a quick test to verify Texture.GetDimensions costs. The code used for the micro-benchmark is like this: (as usual, it is a micro-benchmark with potentially some flaws...)

float2 Texture1Size;
float2 Texture2Size;
float2 Texture3Size;
float2 Texture4Size;
float2 Texture5Size;
float2 Texture6Size;
float2 Texture7Size;
float2 Texture8Size;

Texture2D Texture1;
Texture2D Texture2;
Texture2D Texture3;
Texture2D Texture4;
Texture2D Texture5;
Texture2D Texture6;
Texture2D Texture7;
Texture2D Texture8;
SamplerState PointSampler;

float2 dim(Texture2D textureObj)
{
	uint width;
	uint height;
	textureObj.GetDimensions(width, height);
	return float2(width, height);
}

const float2 MaxSize = float2(1024, 1024);

float4 PSRaw(float2 tex : TEXCOORD) : SV_TARGET
{
	float3 color = float3(tex, 0);
	color += Texture1.Sample(PointSampler, float2(0,0));
	color += Texture2.Sample(PointSampler, float2(0,0));
	color += Texture3.Sample(PointSampler, float2(0,0));
	color += Texture4.Sample(PointSampler, float2(0,0));
	color += Texture5.Sample(PointSampler, float2(0,0));
	color += Texture6.Sample(PointSampler, float2(0,0));
	color += Texture7.Sample(PointSampler, float2(0,0));
	color += Texture8.Sample(PointSampler, float2(0,0));

	return float4(color, 1);
}

float4 PSUsingGetDimension(float2 tex : TEXCOORD) : SV_TARGET
{
	float2 size = dim(Texture1);
	size += dim(Texture2);
	size += dim(Texture3);
	size += dim(Texture4);
	size += dim(Texture5);
	size += dim(Texture6);
	size += dim(Texture7);
	size += dim(Texture8);
	size /= 8;
	size /= MaxSize;

	float3 color = float3(size * tex, 0);
	color += Texture1.Sample(PointSampler, float2(0,0));
	color += Texture2.Sample(PointSampler, float2(0,0));
	color += Texture3.Sample(PointSampler, float2(0,0));
	color += Texture4.Sample(PointSampler, float2(0,0));
	color += Texture5.Sample(PointSampler, float2(0,0));
	color += Texture6.Sample(PointSampler, float2(0,0));
	color += Texture7.Sample(PointSampler, float2(0,0));
	color += Texture8.Sample(PointSampler, float2(0,0));

	return float4(color, 1);
}

float4 PSUsingCBuffer(float2 tex : TEXCOORD) : SV_TARGET
{
	float2 size = Texture1Size;
	size += Texture2Size;
	size += Texture3Size;
	size += Texture4Size;
	size += Texture5Size;
	size += Texture6Size;
	size += Texture7Size;
	size += Texture8Size;
	size /= 8;
	size /= MaxSize;

	float3 color = float3(size * tex, 0);
	color += Texture1.Sample(PointSampler, float2(0,0));
	color += Texture2.Sample(PointSampler, float2(0,0));
	color += Texture3.Sample(PointSampler, float2(0,0));
	color += Texture4.Sample(PointSampler, float2(0,0));
	color += Texture5.Sample(PointSampler, float2(0,0));
	color += Texture6.Sample(PointSampler, float2(0,0));
	color += Texture7.Sample(PointSampler, float2(0,0));
	color += Texture8.Sample(PointSampler, float2(0,0));

	return float4(color, 1);
}

All Texture# are different instance textures bound and at each frame they are cycling by one in order to avoid any driver optim.

All TextureSize# are uploaded at each frame.

 

And the results are:

• PSRaw (sampling directly textures) and PSUsingCBuffer (sampling textures + use of size of each texture) have similar results. Let's take the basis of 1ms (measured from CPU), both having on ShaderAnalyzer an AvgCycle of 3 (I took one card as reference).
• PSUsingGetDimension (sampling textures + texture.GetDimension) is significantly adding an overhead, with 2ms (compare to the previous basis 1ms) confirmed by an AvgCycle of  6 (doubling the results).

It seems quite normal considering the number of instructions that were added when using Texture.GetDimensions (get the size from the texture and convert uint to float).

 

So when we are seeking to save some little GPU cycle, we should better not using Texture.GetDimension and prefer passing Texture dimensions in cbuffer directly.

Definitely C# if you care about "easier" and "faster" development cycles and you are only targeting Windows platforms (Desktop, WinRT, WP8). You can develop in C# on other platforms with Mono but it requires a costly license for each platform.

No matter what you can trick with precompiled headers in C++, you won't have the same fast design-and-run round trip you can have while developing in C#. A typical large scale C# projects with thousands of classes compiles in few seconds, even if you change an API that requires to rebuild all assemblies. Faster compilation cycle implies more refactoring/design options and no fear about making large refactoring when they can help your application to be more future proof. Concerning access to existing underlying C++ API from C#, It really depends on your needs, most of .NET wrappers useful for game dev are often up-to-date (Though OpenTK is seriously lacking some updates from latest 4.3 specs, but I wouldn't use OpenTK for a Windows only project).

Also It will depends a lot on your requirements, and there are several questions that are independent of the language of your choice: What are you willing to develop for your game? Only 2D or 3D? Full game engine from a ground up? Only game logic? What about a scene editor? What about mesh loader/converter? Are you proficient with shaders, GLSL/HLSL languages?...etc.

if you are going to build everything using raw level API like DirectX, prepare to have several months of work to build something useful from this API. If you have strictly no experience with DirectX, this could be even more than a few months. It will be a bit worse with raw C++ and DirectX, as you have to handle yourself the raw nature of the API (sometimes only #defines instead of enums, lots of method check for HRESULT, lots of APIs that are more laborious to work with - DirectInput...etc.). For C#, using MonoGame, or probably SharpDX.Toolkit would help a lot. For C++, DirectXTk would be your best option if you want to have a very minimal bootstrap above the raw API. But they are not game engines, just higher level API around DirectX.

But then, you could also consider using a game engine like Unity3d and concentrate on game logic (The scripting is in C#, under the hood, the engine is in C++ using Mono for the scripting) and you could build a prototype game in just a few hours.

Also, in case you want to access by the name of the variable in your shader and get the slot associated with this name, you can query these slots using D3DReflect (via the ID3D11ShaderReflection or ShaderReflection in SharpDX), and shaderReflection.GetResourceBindingDesc() methods. This is used by legacy D3DX Effect systems. Note that the reflection API is not certified API on the Windows Store App so if you really need this access at runtime, you will have to store them along the bytecode of your shader.

While it can be practical to hardcode these specifics register slots in the original shader, you have less opportunity after this to combine includes/shaders (as you could have some conflicts: for example if you declare in a include TextureA.h a TextureA mapped to register t0, and in TextureB.h a TextureB mapped to register t0, the HLSL compiler will failed at compiling a shader that is using these two variables for the same stage). Though assigning a specific register can be handy in some cases where you want a specific resources to be accessible at a specific slot (for example a particular constant buffer used across all your shaders... etc.), while the others variable could be assigned automatically to the available registers.

@MJP, indeed, unlike D3D9, D3D11 doesn't make any strict assumption about the location of the memory, but a MAP_WRITE_DISCARD needs anyway to allocate a new buffer, even if it is in a shared memory, and the previous memory of the buffer will be released at a later "flush" when It is no longer being used by the GPU. So in practice, when using MAP_WRITE_DISCARD, you are more likely to at *least* double the memory usage (exactly like a double buffering).

After the end of these lines, the amount of memory the program uses is greater than before. If it does in fact keep the vertices stored in main RAM and video RAM, what is the reason for this?

This is expected, as MAP_WRITE_DISCARD requires behind the scene to invalidate the previous buffer, and It has no other ways than to allocate a new buffer on the CPU side before sending it later to a new buffer on the GPU (and releasing the previous GPU buffer). So basically, at the time you use MAP_WRITE_DISCARD, It is not writing directly to the GPU memory, but delaying the writing (and storing this in a temp buffer).

You will only get custom shaders from WP8 using Direct3D11. SharpDX is providing DirectX API for WP8 so custom shaders are working well. But if you want to leverage on XNA, MonoGame is working on a port to WP8 platform - which is using SharpDX (I saw a screenshot on twitter that the port was already working, but you should better check their latest github sourcecode branches/forks)

To create DirectX 11.1 device you need to use different functions. DirectX 11 functions haven't changed so SlimDX should continue working on Windows 8.

Not exactly, with D3D11.1, you create a normal D3D11 device and you query a D3D11.1 interface on it if you want to access the new features.

I'm using SlimDX for Direct X 11 (DX-SDK) development currently under Windows 7 with VS2012. I want to install Windows 8 but my concern is that as SlimDX does not support Direct X 11.1 (Windows SDK) that if I move to Windows 8 I won't be able to work. So I'd like to know if I can have Direct X 11 (DX-SDK) installed on Windows 8 side by side with Windows SDK so that I can keep working normally.

There is no problem installing DirectX June 2010 End-User runtime or SDK on Windows 8, I doesn't interfere with the Windows SDK. From a runtime point of view, your D3D11 application will work without any issues.

There was an attempt two years ago with Gallium "Direct3D 10/11 Is Now Natively Implemented On Linux!", but not sure they have been working on it since then...

Hi All!

I'm glad to announce the availability of a new version 2.4 of SharpDX - a Managed .NET framework supporting the whole DirectX API - with two new major features:

• Adds support for Windows Phone 8: This new version provides full access to WP8 DirectX from .NET (Direct3D11.1, XAudio2, MediaEngine). It allows you to add 3D content seamlessly integrated into your XAML DrawingSurface very easily. Like SharpDX for Windows RT, you can develop a game using Direct3D from .NET without using C++.
• New SharpDX.Toolkit (beta), a high level API that greatly simplifies access to Direct3D11 by providing a XNA like API with the full power Direct3D11.1 The toolkit allows you to develop a 3D application to target Windows Desktop, Windows RT or Windows Phone 8 using exactly the same code base.

You can find more information here.

Since this topic is up I have another question, the fullscreen method I use at present is very similiar to the one in your link, same results different methods, it acts much like Windows Mode [Fixed] in games and is really decent but I often wonder the real difference between playing games in Fullscreen mode / Windows Mode [Fixed] or Windows Mode in general, now this may just be me but I find Fullscreen to look better though I have never actually known why. In terms of quality do games 'look' better when in fullscreen?

I'm not aware about a quality improvement when a backbuffer goes to fullscreen (apart from some color correction that could be applied in fullscreen differently by the gfx card?, not sure). The main difference is that for a plain window there is a copy (a blit) from the back buffer to the front buffer while in fullscreen mode, it is just a flip (see msdn doc about DXGI), plus the fact that the surface will go through Windows Manager composition, so It is usually slower and you can have less guarantee on the FPS/vsync in Window mode.

I don't think that WPF is supporting fullscreen mode with full control of the output monitor handled by DXGI swap chain as it can be done with WinForm. The only thing that you could do is probably to fake WPF form to look like a fullscreen app, like this. Also, when operating with WPF, you usually don't use a swap chain, as the process of copying/surface sharing with d3d9 is not using it.

Very nice, I didn't realize you've released code for your toolkit (I heard mentions of it a while ago). But yeah, exactly the process that I've went with.
FYI, TinyPG produces code for a scanner/parser/parsetree, so there isn't any runtime dependencies. All you write is a grammer (e.g. terminals, production rules to parse and evaluate technique/pass expressions, etc). It's a lot simpler than writing out your own parser by hand.

TinyPG is indeed really nice and the generated code is concise and relatively efficient. But there are a couple of things that would require probably some changes to TinyPG in order to parse correctly HLSL with preprocessor:

• For example, in my case, I parse and build an AST only for a technique block, everything else is eaten by the parser but skipped. I'm only checking that all braces {}[]() are matching until a technique is found.
• I'm handling preprocessor (though D3DCompiler.PreProcess) and parsing #line directive in order to provide the exact line/file error from an included file. This would probably required some changes in TinyPG generated code or at least quite some code to re-process all parse tree errors and adjust line (and provide file information). Also a preprocessor doesn't fit well with a general grammar as it can be interleaved everywhere, so most of the time, you need some entry point between the scanner and the parser in order to handle them correctly (and I don't think that TinyPG has this kind of extension points).

And even then, you can still use the FX file format - the difference is you'd have an offline compiler tool that parses the format for techniques/passes in order to acquire the necessary shader profiles + entry points. So with the profile/entry point in hand, you can run the FX file through the D3DCompiler to get a ShaderByteCode object for each shader, then use that to create a reflection object to query all your meta data. Then write out the reflected meta data to a file, that gets consumed by your application at runtime - which would be your own implementation of Effects11 (or something completely different, either way...you use the meta data to automatically setup your constant buffers, bind resources, and manage the shader pipeline by directly using the Direct3D11 shader interfaces).

For parsing, you can use something like Tiny Parser Generator, which is a really neat little tool if you know how to create a grammar. This is a problem that I've been working on myself for my own software and the approach has been working out pretty well (and frankly, I love TinyPG). I also believe the MonoGame folks have adopted this method, so that may be a good place to gather some ideas.

You are right, that is basically what has been done recently in SharpDX.Toolkit to support parsing of HLSL FX shaders:

- I decided to almost parse fx file format (only the content of technique/passes) in order to keep things quite compatible with legacy shaders and ease porting (though the syntax is slightly simplidied and different, check for example BasicEffect.fx link below)
- Write a parser, done by hand (nothing more than a couple of hundred of lines) and is mainly parsing technique/passes and the content of a pass, but the syntax supported is slightly closer to D3D9, producing an AST.
- Write a custom metadata fileformat (EffectData in the toolkit) that is able to save the whole description of a shader (shader bytecodes, constant buffers, value & resource variables, techniques/passes), nice thing is that It supports multiple effects inside a same archive that can be merged (like a zip of effects)
- Write a compilerthat takes the AST produced by the parser and compile all shaders and put them in the metadata format.
- A command line tool "fxc.exe" like called "tkfxc.exe" which basically allow to generate an archive of effects (unlike legacy FX, I can then put several effects inside the same tkfxo file), it is also outputing a friendly colored output as the original fxc.exe.
- Then you have to rewrite the whole Effect framework

Getting all this efficiently written is really really a long way (correct handling of constant buffers update, minimize calls to XXSetShaderResource/SetSamplers...for each shader stages...etc.), but in the end the result is pretty close to XNA effects (thus, I have been able to reuse all StockEffects from XNA, for example BasicEffect.fx is very similar to the original one, only techniques/passes declaration is slgihtly changing) but a bit more flexible as It can provide some extras features like linking of shader declared from another shader (export/import of a particular shader shareable between effects), or constant buffer pooling, or automatic access to all non-builtin variable declared in the effect pass at runtime (if you declare Toto = 1.0f; in the effect pass, you will be able to get this value from C#).