Since my application will be rendering thousands of textured quads per frame, I figured I might finally make more use of the GPU to preserve CPU speeds... So I've made the move up to the land of shaders and all the shiny new features of D3D10 and 11, so that I can truly put my graphics card to the test.
So far, I've been able to render a fullscreen quad using a triangle strip and a basic vertex & pixel shader... so naturally the next step would be to slap a texture on there. From my understanding, this would be the pixel shader's job, correct? You would pass texture data and UV coords to the pixel shader (instead of a color), and it would light the vertices based on the pixel colors of the texture data?
Anywho... after researching several tutorials (and poking at code in both C++, C# and VB), the only working examples of what I'm going for were found in unmanaged C++.
SlimDX aids me in the managed world, as it's mostly identical to unmanaged D3D. But I can't figure out the proper way to set up a resource chain capable of sending mutable texture info to the shader, and how to modify it's contents during each frame. The example I was porting used BasicEffect, BasicTechnique, and GetVariableByName()->AsShaderResource to set it up, but the only managed examples I can find use ShaderByteCodes instead.
Peek at this unmanaged tutorial see what I mean: http://takinginitiat...ial-3-textures/
With all these differences, I've stumbled into a "chicken or the egg" paradox, and I'm not sure where to go from here.
TL;DR:
Does anyone have a barebones example of setting up a resource chain to load and manipulate 2D texture info in an HLSL shader?
Textured quads in DirectX10/11 [SlimDX]
How exactly are you trying to manipulate texture info, here. That's not usually something you'd need to do in the context of what you describe.
Unless, of course, you're trying to bind textures to the shader-- that's pretty straightforward. In the unmanaged world, give the PSSetShaderResources() method a look; you'll need to figure out the slot of the texture/buffer/whatever by examining the shader's reflection information.
Unless, of course, you're trying to bind textures to the shader-- that's pretty straightforward. In the unmanaged world, give the PSSetShaderResources() method a look; you'll need to figure out the slot of the texture/buffer/whatever by examining the shader's reflection information.
Author
Oh sorry, I should've mentioned that this is for a managed project (SlimDX). I understand how it works in the unmanaged world, but not so much in C# and VB.
And yes I'm trying to assign a texture to a quad. In D3D8 this was simple, and didn't appear to be any different for D3D9, but now I'm trying to understand how to do it using shaders in D3D10 and D3D11 using a managed language. Moreover, I'm trying to understand how the textured quad can be manipulated in the shader model (things like scaling, transformations, and changing texture coordinates for sprite animations) from a managed language. It appears in C++ that these variables are manipulated more directly than what would be allowed in C# and VB, and if there's no good means of doing so without a great loss of CPU power than I don't see much point in even having managed D3D.
And yes I'm trying to assign a texture to a quad. In D3D8 this was simple, and didn't appear to be any different for D3D9, but now I'm trying to understand how to do it using shaders in D3D10 and D3D11 using a managed language. Moreover, I'm trying to understand how the textured quad can be manipulated in the shader model (things like scaling, transformations, and changing texture coordinates for sprite animations) from a managed language. It appears in C++ that these variables are manipulated more directly than what would be allowed in C# and VB, and if there's no good means of doing so without a great loss of CPU power than I don't see much point in even having managed D3D.
In that case, looks like this is what you're after, and this method in particular. As mentioned, you're going to need to figure out the resource index (parameter #2) by looking at the shader reflection info, some information here.
Constants are going to work in a very similar fashion, except you're going to be reflecting and setting constant buffers instead of shader resources. A good example of this would be offsets or scale values for a sprite card (though if you're atlasing/instancing it may be beneficial to send this in a vertex attribute stream for better batch efficiency) or any other time you want to send 'parameters' to the 'function' the shader(s) describe. Most of the actual mathy bits of that are going to take place in the shader anyways, you can freely refer to managed or unmanaged documentation and adapt the app-side function calls to your needs.
Constants are going to work in a very similar fashion, except you're going to be reflecting and setting constant buffers instead of shader resources. A good example of this would be offsets or scale values for a sprite card (though if you're atlasing/instancing it may be beneficial to send this in a vertex attribute stream for better batch efficiency) or any other time you want to send 'parameters' to the 'function' the shader(s) describe. Most of the actual mathy bits of that are going to take place in the shader anyways, you can freely refer to managed or unmanaged documentation and adapt the app-side function calls to your needs.
Author
Yeah I was afraid of that. Since speed and efficiency are my top priorities here, I've started porting the render loop into a C++/CLI library. No more SlimDX, just raw DX10.
This means loads of more work (especially in dealing with crossing native/managed boundaries), but better access and execution to whatever D3D objects need attention.
I was really hoping to get this done sooner, but I figured it would eventually come to this. Now the only real problem is dissecting the design so it works well in C# and VB, which I'll probably end up having to do more than once.
Thanks for the help.
This means loads of more work (especially in dealing with crossing native/managed boundaries), but better access and execution to whatever D3D objects need attention.
I was really hoping to get this done sooner, but I figured it would eventually come to this. Now the only real problem is dissecting the design so it works well in C# and VB, which I'll probably end up having to do more than once.
Thanks for the help.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
