Archived

This topic is now archived and is closed to further replies.

TrigonLoki

D3D8 Transform Woes

Recommended Posts

Well, here we are, some newbies (to D3D, at least) asking a (probably) obvious question. But here goes anyway! We have 2 textured polygons (henceforth called polys so we can sound coool) that we are drawing on the screen. pic1 (a CPic, which is a class we made that contains a CPrimitive, another class we made) is 64x64 with one texture, and pic2 is another poly, which is 32x32 and has a different texture. Our problem is that the transforms to position the polys are being applied to the wrong polygons. For example, we set pic1 to draw at (-100, -100) -- it''s one of those 2D/3D engines, so the Z coordinate is constant. We set pic2 to display at (100, 500), and is to be rotated 32 degrees. Also, in the Update() code, pic1 is moved a few pixels every frame. When the program runs, every transform that was meant to apply to pic1 is applied to pic2, and vice versa. Pic1 is rotated and at (100, 500), and pic2 starts at (-100, -100) and moves. Yikes. Heres the code for DrawScene():
void DrawScene()
{
	g_hr=g_pDevice->Clear(0,NULL,D3DCLEAR_TARGET,D3DCOLOR_ARGB(0,0,0,0),0.0f,0);
	g_hr=g_pDevice->BeginScene();
	pic1.Draw();
	pic2.Draw();
	g_hr=g_pDevice->EndScene();
	g_pDevice->Present(NULL,NULL,NULL,NULL);
}
 
That doesn''t help much, does it? CPic::Draw() is a wrapper for the CPrimitive::Draw() function (every CPic has a CPrimitive which holds all the position and texture information). So here''s the CPrimitive::Draw():
void CPRIMITIVE::Draw()
{
	float zoomoffset = 0.0f;
	if (!zoomable)
	{
		zoomoffset = CAMERADIST - dist;
	}
	else
	{
		zoomoffset = dist;
	}
	g_pDevice->SetStreamSource(0,temp,sizeof(CVERTEX));
	g_pDevice->SetVertexShader(D3DFVF_CVERT);
	g_pDevice->ProcessVertices(0,0,NOV,pVertexBuffer,NULL);
	g_pDevice->SetTexture(0,tex);
	// Transformation
	D3DXMATRIX translation;
	D3DXMATRIX rotation;
	D3DXMATRIX final;
	D3DXMatrixTranslation(&translation,posx,posy,zoomoffset);
	D3DXMatrixRotationZ(&rotation,D3DXToRadian(rotz));
	D3DXMatrixMultiply(&final,&rotation,&translation);
	g_pDevice->SetTransform(D3DTS_WORLD,&(D3DMATRIX)final);
	g_pDevice->SetStreamSource(0,pVertexBuffer,sizeof(CProcessedVertex));
	g_pDevice->SetVertexShader(D3DFVF_CPVERT);
	g_pDevice->SetTextureStageState(0,D3DTSS_COLOROP,D3DTOP_MODULATE);
	g_pDevice->SetTextureStageState(0,D3DTSS_COLORARG1,D3DTA_TEXTURE);
	g_pDevice->SetTextureStageState(0,D3DTSS_COLORARG2,D3DTA_DIFFUSE);
	g_pDevice->SetTextureStageState(0,D3DTSS_ALPHAOP,D3DTOP_DISABLE);
	g_pDevice->DrawPrimitive(D3DPT_TRIANGLESTRIP,0,NOV-2);
}
 
As you can see from the code above, we follow a pretty standard system for transforms (i.e. transform the world matrix, draw it, that''s standard, right?), but obviously we''re doing something wrong... We would appreciate any help that could be given. Thank you. Pat & Jake

Share this post


Link to post
Share on other sites
G''day!

Your problem is the ProcessVertices call. You don''t need it and shouldn''t use it. ProcessVertices is doing the transformation and then your world matrix is being ignored by the DrawPrim call.

ProcessVertices creates Transformed Vertices. Transformed vertices are not affected by the current world matrix, they have screen coordinates.

ProcessVertices DOES use the current world matrix, which because of the way things are organized will be the world matrix for the other object.

What you should do is associate a Vertex Buffer with each object, then just set the world matrix and do a DrawPrim call.

Let me know if that doesn''t make sense. There are a number of tutorials on my site (www.drunkenhyena, just click my sig) that you might find helpful.


Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites
Thank you so much for your help. Your advice helped greatly. My friend didn''t want to rewrite all of what he had done so far so that processed vertices weren''t used, but we solved the situation by moving the ProcessVertices() call to a point after the world matrix is set.

Thanks again (now we''re having more adventures trying to convert the thing to a .dll, but it''s actually going pretty well...er, kind of)

I''m sure we''ll be on posting about that at some other time.

Jake (him) & Pat (me)

Share this post


Link to post
Share on other sites