Tag Info

New answers tagged

2

I think the problem is with the semantics used. As far as I know, pixel shader can only recieve SV_POSITION - if talking about POSITION (which is filled usualy by vertex shader POSITION0 semantics) The only user-defined semantics you can recieve in pixel shader are: COLOR[n] TEXCOORD[n] The behavior you're describing is because these are two different ...


2

Similar to solution #3 in your answer, but perhaps a little cleaner in that no device state will be modified: you could create an ID3DXEffectStateManager that no-ops all of the operations, but tracks the index to which your dummy texture was assigned. (You could also use your custom state manager to snoop the sampler state settings.)


3

A given shader model exposes a particular set of registers to HLSL; these registers are underlying hardware registers on the GPU, like CPU registers, but have more refined scopes (for example, there are registers dedicated to holding samplers). Registers are where all your data is stored during the execution of your shader (with the exception of data, like ...


2

You need to make sure that any variable you use within the constant buffer does not cross a 16 byte alignment boundary, or you won't be able to access it from the shader. For example, you could have a constant buffer that looks like this: struct constant_buffer { XMFLOAT4X4 wvp; // 64 bytes -> 16 byte aligned = OK XMFLOAT3 position; // 12 ...


0

Registers are a type of storage that is located on a processor, and accessible very rapidly. They are typically substantially smaller, and are used as input and output locations for processor instructions. HLSL provides a method for mapping up data to these registers from the CPU side, to be used within your shader on the GPU. They should be used whenever ...


1

Vertex tweening for animation is an outdated technique, and there aren't many good reasons to use it in modern graphics code. I'm fairly certain it isn't even supported at the API level in D3D10+ (although you could always still implement it yourself). One of the big problems with it is that it requires complete copies of the vertex data for each keyframe, ...


2

First of all, to create this kind of effect you're going to need more than 4 vertices. You can move the vertex positions around all you like, but a shape made with 4 vertices will only ever be a quadrilateral, not a shape with wavy sides like you've shown. You'll have to subdivide the shape vertically, at least, so that it has enough vertices along each ...


0

I fixed the issue myself! After some more testing I found out that even if the lightmap would make the full scene overbright (just like it would when it was forcefully disabled in the HLSL), it still generated black shadows. Because of this discovery I went back to my texture declaration: LightMaps[i] = new Texture(GameHelper.Device, ...



Top 50 recent answers are included