Hi.
I had the following constant buffer
Hi.
I had the following constant buffer
as far as i understand both would use the same 12 bytes
Actually, because the variables in the buffer don't appear in GPU "memory" as they do on the CPU, the buffers you cite do not occupy the "same" 12 bytes. When a constant buffer gets loaded, each variable is loaded into 1 (or more) registers, each register comprising 4 float values. E.g., float3 w get loaded into 1 register. float w1, w2, w3 gets loaded into 3 separate registers.
If you have a graphics debugger (such as GPUPerfClient or the like), and you can look at the assembled shader code, you can see the difference in the loading code.
To determine why the second buffer you list above didn't work, you'd have to post the code for updating the resource and, possibly, the shader code that accesses the variables.
Ok. I am busy writing a java directx wrapper in c++ to add directx support to my java game engine which only supported opengl up til now. C++ is also completely new to me same as directx so i might be making silly mistakes. I didnt know that constant buffers were futher split into registers.
Here is the relevant c++ code that creates and updates constant buffers. when updating A constant buffer I basically just point to a raw array of bytes. I handle the layout of that byte array java side only.
[source]
[/source]
EDIT: ok so you said everything is stored in 16 byte (4 float right?) registers. By that Im thinking im just building up that array incorrectly. When i changed al my float3's to float 4's it started working perfectly. Then i thought i should simply pad my float3's with 4 bytes at the end so they fit into 16 bytes instead but that doesnt seem to work.
HLSL has some weird packing/alignment rules for constant buffers due to legacy hardware issues. The rules are described here, and I would suggest reading them.
What's getting you in this case is that your "w" value will get aligned to the next 16-byte boundary to satisfy the packing rules, which state that a vector type can't span a 16-byte boundary. So when w is a float3 it will start at byte offset 80, but when you use scalar types they start at byte offset 76.