Jump to content
  • Advertisement
Sign in to follow this  
Radan

Unable to get correct colours on a triangle(*SOLVED*)

This topic is 3940 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was writing some simple DX9 code in VS2005 C++ and just to see if my initialization is ok I decided to put screen aligned vertex coloured triangle on screen. I'll leave out the unimportant stuff. Vertex structure I am using is:
  struct CUSTOMVERTEX
		{
			FLOAT x, y; // The transformed position for the vertex
			D3DCOLOR colour;        // The vertex color
		};





I build my very simple HLSL shader:
struct a2v
{
  float2 Pos:POSITION;
  float4 colour : COLOR0;
};
struct v2p
{
  float4 Position : POSITION;
  float4 colour : COLOR0;
};
v2p main(in a2v ulaz : POSITION)
{
  v2p Output;
  Output.Position = float4( ulaz.Pos.x, ulaz.Pos.y, 1.0f, 1.0f);
  Output.colour = ulaz.colour;
  return Output;
}

struct p2f
{
    float4 color : COLOR0;
};

void ps( in v2p IN, out p2f OUT )
{
    OUT.color = IN.colour;
};


It builds just fine , D3D_OK. I set my vertex declaration:
    D3DVERTEXELEMENT9 decl[] =
    {
        { 0, 0, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0 },
        { 0, 8, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0 },
        D3DDECL_END()
    };


and I fill my vertex buffer(VertexPointer is coming from the Lock on VertexBuffer):
  CUSTOMVERTEX temp[] =
  { 
    {0,0,D3DCOLOR_RGBA(0,0,255,255)},
    {1,0,D3DCOLOR_RGBA(255,0,0,255)},
    {0,1,D3DCOLOR_RGBA(0,255,0,255)}
  };

  memcpy(VertexPointer, temp, sizeof(temp));


When I run the code I get a nice WHITE triangle across the screen. If I try changing the vertex coordinates the vertices move as expected but whatever I set my colour to I am getting just white vertices, as if the colour is not there and the pipeline is defaulting to white. This is where the weird part comes in. I looked for a very simple example of a single vertex coloured triangle on the net. I found this. Perfect. Even though it is in C# I downloaded it and ran it. It works fine. I ran my program right after that example without changing it and I got colour. BUT, I wasn't getting the colour I set, I was getting the exact same colours that example set. If I change colours in the example I get the new colours in my program (after I run the example with the new colours). I am obviously forgetting something in my code that is stopping the colours from reaching the Vertex Shader but I don't see how can I be getting that example's colours. I mean the example is sending over FLOAT3 for the position and I am sending over just FLOAT2 so colour bytes in our vertex structures are not even aligned. EDIT: **UPDATE** Ok, I think I have narrowed down my problem. I tried debugging the program in PIX. What I got from PIX that I think shows the source of my problem is the disassembled vertex shade code (HLSL code is the one listed in this post, little bit above):
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.19.949.2111
    vs_2_0
    def c0, 1, 0, 0, 0
    dcl_position v0  // ulaz<0,1>
    dcl_position1 v1  // ulaz<2,3,4,5>

#line 14 "D:\DataTestDir\test.vsh"
    mad oPos, v0.xyxx, c0.xxyy, c0.yyxx  // ::main<0,1,2,3>
    mov oD0, v1  // ::main<4,5,6,7>

// approximately 2 instruction slots used


The problem should be in the dcl_position1 v1 // ulaz<2,3,4,5> line, where v1 is declared as POSITION1 while it should be COLOR0, as in the HLSL code. Obviously , the pipeline is falling to fill in the v1 register with color data because it is declared wrongly. This is the code with which I Build the shader:
  LPD3DXBUFFER ppShader;
   
  BuildResult = D3DXCompileShaderFromFileA(filename.c_str(),NULL,NULL,
                                   MainFunctionName.c_str(),"vs_2_0",D3DXSHADER_DEBUG,
                                   &ppShader,NULL,NULL);

  if (BuildResult == D3D_OK)
  {
    BuildResult = pDevice->CreateVertexShader( (DWORD*)ppShader->GetBufferPointer(),
                                               &pVertexShader );

    ppShader->Release();
  }


filename and MainFunctionName are std::string, containing the full path to the shader file and "main", respectively. I have the latest Catalyst Drivers, and November SDK. I would be really grateful for any Help. I know this is something simple and stupid, maybe I'm messing up memory somewhere, cause It is not very likely that D3DXCompile has a bug of this kind. Thank you in advance. [Edited by - Radan on November 7, 2007 6:15:12 AM]

Share this post


Link to post
Share on other sites
Advertisement

D3DVERTEXELEMENT9 decl[] =
{
{ 0, 0, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0 },
{ 0, 0, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0 },
D3DDECL_END()
};



Yeah the offset isn't correct here, look up D3DVERTEXELEMENT9 in the D3D docs. The second item in the struct is a WORD offset which you have to increase for each type in the declaration. So in your case you have D3DDECLTYPE_FLOAT2 which is two, four byte floats so as ToohrVyk said an offset of 8.

Share this post


Link to post
Share on other sites
EDIT: Too slow [rolleyes]

Firstly, please remember to use a descriptive subject title "Weird behaviour" is completely and totally useless to the very people you're hoping will click on your thread and provide you with an answer [wink]

{ 0, 0, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0 },
{ 0, 0, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0 },


At a glance, this appears to be wrong - you have both elements offset to the same location, so it's probably mapping (or failing to map) the same input elements to the same bytes.

Run the debug runtimes, they're usually good at spotting this sort of thing.

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
Your offset values in the D3DVERTEXELEMENT9 array are weird—shouldn't the colors be at offset 8?


Sorry, in the code they are at offset 8. I was just leaving out some temp variables I was using to make to code more readable for others (i.e. you). I'm calculating the offset from the size of the variables before them.

Anyway it is actually 8 in the code, I just double-checked with a breakpoint. Thanks for the heads up.

EDIT: WOW, two more answers on the same thing before I could type this up. Sorry for the typo. It was a bad one.

Share this post


Link to post
Share on other sites
UPDATE

I tried "cheating" by sending in the colour as something else. I'm sending three FLOATs that I interpret as r,g,b values.

When I send them, in the vertex declaration, as NORMAL i don't get the colours. However, If I send them over as POSITION1 everything works just fine. I get the numbers I set.

If anyone has a plain example of a code displaying a coloured triangle in DX9 with C++ and programmable pipeline I would be grateful if you could e-mail it to me. The simpler the code the better. :)

This is probably some very simple and stupid mistake that I keep overlooking like a blind spot. If I had a code example it would only be a matter of factoring out the difference, which shouldn't be a problem.

[Edited by - Radan on October 31, 2007 6:35:47 AM]

Share this post


Link to post
Share on other sites
*Bump*

Well, could someone at least verify that what I wrote up in the original post should be enough to get the colours as expected? Could you verify for me that it appears that I did not forget anything? Nothing like, for example, a render state I might have missed out?

Share this post


Link to post
Share on other sites
Please look at the end of the original post, I have jest added the part marked with

EDIT: **UPDATE**

As is said there, it appears as if for some odd reason my shader is not being compiled correctly.

Share this post


Link to post
Share on other sites
v2p main(in a2v ulaz : POSITION)
You're marking your entire vertex shader input struct as position. Remove this semantic completely, you don't need it, since each element in the struct has its own semantic.

Share this post


Link to post
Share on other sites
KUDOS to you my friend.

Initially I had just the position, I forgot to remove the semantic. I feel really silly now. The posters above you missed it as well.

Because I wrote the code and it was so simple I was reading over that place as if it wasn't there cause I knew what should be written there.(as I said , like a blind spot)

Thanks a lot. :)

rate++;

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!