Translating Transformed Vertices

Hullo hullo.

I'm in a 2D jam. I've got a some Transformed vertices:

Code:

---

#define D3DFVF_CUSTOMVERTEX (D3DFVF_XYZRHW|D3DFVF_DIFFUSE)

---

And I'm trying to use:

Code:

---

D3DXMATRIX matTrans;
       
    Kinetics.Update();
       
        m_pD3DDevice->SetVertexShader(D3DFVF_CUSTOMVERTEX);
        m_pD3DDevice->SetStreamSource(0, m_pVBuffer, sizeof(CUSTOMVERTEX));

        D3DXMatrixTranslation(&matTrans, (float)Kinetics.pX, (float)Kinetics.pY, 0.0f);

        m_pD3DDevice->SetTransform(D3DTS_WORLD, &matTrans);

    m_pD3DDevice->DrawPrimitive(D3DPT_TRIANGLEFAN, 0, 2);

---

Kinetics.Update just assigns new values to pX and pY each time.

However, my fancy little box is just sitting still. Is this not a valid method to move vertices in screen space? If not, are there any suggestions on how to do it?

Thanks

The transformation is not being applied because when you specify RHW you are saying the vertices are already transformed and lit so don't let DirectX do it.

That having been said, you can just make a dynamic vertex buffer and update the verts by locking , changing, unlocking whenever you need to. You may want to look at the ID3DXSprite interface for a very nice 2D interface.

I never really understood what RHW was. I've been using DirectX for a long time now, but never really looked in-depth into all of this FVF declaration stuff/picking what suits my needs.

I'm hoping to stay away from the Locking/Unlocking method. Each scene will be updating about 8 Million vertices (perhaps a touch ambitious). And just that (without having to Lock/Unlock inbetween) is going to end up taking a lot of resources.

Oh a whim, I removed the RHW property, made the necessary adjustments to classes/declaration of vertices, and disabled the D3DRS_LIGHTING property. Now my box has gone AWOL. I take it this wasn't a valid alternative?

So now that you have removed RHW DirectX will transform and light your vertices for you. Now you have disabled lighting so we are just transforming your vertices. Make sure you have your world matrix, camera matrix and projection matrix all set to appropriate values.

If you don't have a lot of vertices the added complexity and performance hit of locking/unlocking the buffer might be overkill. I would simply use an array of your own vertices and then use DrawPrimitiveUP to render them. Then to change the position you do not need to unlock or lock anything. Downside is that your vertices are going to be stored in system RAM which means they must be passed across the AGP bus as opposed to being stored in Video RAM and being passed directly to the GPU via the internal video card bus.

But locking and unlocking is extremely costly and if you do that for every 2D object in every frame - it's going to be a mess.

If you insist on unlocking/locking I might suggest you use a vector of vertex buffers that require unlocking and locking. At the start of the frame Lock all of them. At the end of the frame unlock them. This guarantees that you will only lock/unlock each vertex buffer only once. However I really don't recommend using IDirect3DVertexBuffer9's for this type of thing.

Hmm, I was hoping to avoid having to set up the Camera and Projection Matrices, but I guess if I just stick to an Orthoganal Camera, it would be alright. Everything is strictly going to be 2D, and I was just looking for the quickest setup that would involve the least amount of per-frame calls.

I'll look into the DrawPrimitiveUP function, I haven't seen the "UP" ending before. I'm also not very familiar with vectors in this sense, but I'll give it some thought too.

The key thing right now is speed, and from what I'm thinking, perhaps setting up these matrices is the way to go. That way I have my 4 vertice box, and I'll just call D3DXMatrixTranslation, oh, only about 2 Million times.

Thanks for the tips.

I've been staring at this code for about three hours now. My little box just doesn't want to come back...
Note: These are pieces of my files.

Code:

---

CAMERA AND PROJECTION INITIALIZATION
D3DXMATRIX matOrtho;
D3DXMATRIX matIdentity;

D3DXMatrixOrthoLH(&matOrtho, (float)GetSystemMetrics(SM_CXSCREEN), (float)GetSystemMetrics(SM_CYSCREEN), 0.0f, 1.0f);
D3DXMatrixIdentity(&matIdentity);

m_pD3DDevice->SetTransform(D3DTS_PROJECTION, &matOrtho);
m_pD3DDevice->SetTransform(D3DTS_WORLD, &matIdentity);
m_pD3DDevice->SetTransform(D3DTS_VIEW, &matIdentity);

m_pD3DDevice->SetRenderState(D3DRS_CULLMODE, D3DCULL_CCW);
m_pD3DDevice->SetRenderState(D3DRS_ZENABLE, false);
m_pD3DDevice->SetRenderState(D3DRS_LIGHTING, false);

VERTICE INITIALIZATION
HRESULT Status;
const int NUMVERTICES = 4;
       
m_pD3DDevice = pD3DDevice;
if(m_pD3DDevice == NULL)
        return E_FAIL;
       
CUSTOMVERTEX *pVertices = NULL;

Status = m_pD3DDevice->CreateVertexBuffer(NUMVERTICES * sizeof(CUSTOMVERTEX),0,D3DFVF_CUSTOMVERTEX,D3DPOOL_DEFAULT,&m_pVBuffer);
if(FAILED(Status))
        return E_FAIL;

Status = m_pVBuffer->Lock(0, NUMVERTICES * sizeof(CUSTOMVERTEX), (BYTE**)&pVertices, 0);
if(FAILED(Status))
        return E_FAIL;

pVertices[0].Colour = pVertices[1].Colour = pVertices[2].Colour = pVertices[3].Colour = D3DCOLOR_XRGB(0, 200, 0);
pVertices[0].Z = pVertices[1].Z = pVertices[2].Z = pVertices[3].Z = 0.0f;
pVertices[0].X = pVertices[3].X = -(PIXELWIDTH / 2.0f) + 50.0f;
pVertices[1].X = pVertices[2].X =  (PIXELWIDTH / 2.0f) + 50.0f;
pVertices[0].Y = pVertices[1].Y = -(PIXELHEIGHT / 2.0f) + 50.0f;
pVertices[2].Y = pVertices[3].Y =  (PIXELHEIGHT / 2.0f) + 50.0f;

m_pVBuffer->Unlock();

RENDERING
m_pD3DDevice->SetVertexShader(D3DFVF_CUSTOMVERTEX);
m_pD3DDevice->SetStreamSource(0, m_pVBuffer, sizeof(CUSTOMVERTEX));

m_pD3DDevice->DrawPrimitive(D3DPT_TRIANGLEFAN, 0, 2);

---

My understanding was that with an Orthogonal Camera Setup, the centre of the screen is the origin (0, 0), and goes from -1/2 of the value to +1/2 of the value passed into the D3DXMatrixOrthoLH() Initialisation.

Note: I'm drawing a Triangle Fan (Hence the funky vertice declarations. Though I'm sure most of you would've picked up on that anyways).

Any thoughts?

That code looks pre-DirectX 9.0

Right you are. That's my bad though, I should've mentioned I'm in DX8. (I still haven't made the switch over to 9 and I keep forgetting people are actually using it over 8.)

I'm not in the wrong section of the forums am I?

When you don't see your rendered objects it is usually because of one of these reasons.

• Incorrect alpha state. Object is at 0 alpha.
• Cull mode is incorrect or vertices are ordered in opposite direction of current cull. For all tests I set cull mode to D3DCULL_NONE. This ensures that your object, if translated correctly and setup correctly, will be shown. Then toggle between CCW and CW to see if your ordering is off.
• Object has been translated off-screen. This can be due to many factors, some unforeseen or overlooked. It's all about coordinate spaces and often times not seeing an object is the direct result of the programmer using the wrong coordinate space at the wrong time or using the coordinate space incorrectly.
• Colors of the vertexes are not being sent to Direct3D. Check the FVF declaration. Make sure the FVF matches not only what is in your vertex structure but that the FVF declaration matches the ORDER in which they appear in your structure.
  I.E.:
  
  struct Vertex
  {
  D3DXVECTOR3 x,y,z;
  D3DCOLOR Diffuse;
  D3DCOLOR Specular;
  float u,v;
  
  static const DWORD FVF;
  };
  
  The correct FVF for this is:
  
  const DWORD Vertex::FVF=D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_SPECULAR | D3DFVF_TEX1;
  
  Notice the declaration matches the contents of my structure as well as the order. This is extremely important and will help you later. Some tutorials overlook this and IMO miss a key issue in avoiding simple errors.
• The primitive you are creating or sending to DirectX cannot be rendered correctly given your vertex information/ordering. This usually means your object is being created incorrectly or the vertices cannot be used by DirectX to create a triangle fan, triangle strip, line list, etc. Check the SDK. I will tell you that for clockwise ordered quads the correct triangulation for a triangle strip is:
  0................1
  ....................
  ....................
  ....................
  ....................
  2.................3
  
  Any other order will cause DirectX to FAIL TO RENDER the primitive because it cannot correctly process the vertexes.
• Stream stride value is incorrect for your vertex format. For vertex buffers make sure the stream stride value is correct. It should be sizeof(vertex_struct). Any other value will cause incorrect intepretation of the data you are sending. Sometimes this produces weird results. For instance it may just so happen that your primitive is displayed, but something isn't right. So you look in the wrong place for the bug when all along it is because your data alignment is incorrect. This is a very annoying bug. Always make sure your vertex stride member is sizeof(vertex_struct). This will take care of any constructors or other data you are storing in the vertex buffer.
• Incorrect FVF for the vertex. Sometimes the error is as simple as your FVF declaration being incorrect. For instance if you declare the vertex to have a diffuse and specular color, yet only specify D3DFVF_DIFFUSE - the color will not render correctly because the lighting engine will not use the specular color. So you could change the specular color all day long and it would NEVER affect the specular component of the primitive. The image will still render correctly if you are using sizeof(vertex_struct) which may lead you to the false assumption that your specular color is simply wrong. You change it and still no effect. Make sure the FVF has all the required members for your vertex. The same holds true for making sure your struct has all the components of the FVF declaration.
• No light is reaching your object. Basically in 3D if there is no light....there is nothing there. So Direct3D is rendering a pure black primitive. One good way to test this is to clear the backbuffer in pure blue or pure red (0,0,255,255 or 255,0,0) and render the scene. If you see a bunch of pure black objects then your problem is lighting. There are two solutions to this. Either turn lighting off and specify to DirectX that the light value for the vertex comes from the vertex itself or you can put a D3DLIGHT9 in your world. Directional lights are the easiest and least costly. Check the SDK.
• No material specified for your 3D object or primitive, If you are using Direct3D's default lighting engine it is very possible that your material properties are incorrect. Also if you use the lighting engine your object MUST have a material or you MUST specify the vertex colors in the vertex itself or Direct3D cannot light the vertexes. No material=no light. If it does not compute the light reaching the vertexes or the color at the vertexes correctly then it interpolates from 0.0f to 0.0f which is 0.0f - black. If you are clearing the screen to black then you wouldn't see anything rendered.

I've looked at your code and according to your setup your object should be at 0,0,0 in world space and camera space. Try setting the vertex z components to something a tad above 0.0f. It could be that they are being culled by the near clip plane. Try .1f or .2f. 0.0f should work, but its worth a shot.

Incidentally quads are more suited to D3DPT_TRIANGLESTRIP than fans.

Also for your update function when using a custom vertex buffer.

Code:

---

...
for (int i=0;i<num_vertexes;i++)
{
  Vertexes[i].x+=increment_x;
  Vertexes[i].y+=increment_y;
}

---

But instead of incrementing you could also just directly assign the vertices a new absolute position.

Hey Bubba,

Thanks for the in-depth reply. I went through each of those suggestions and still could not find the error.

I noticed myself too that the Orthogonal View bounded Z between 0.0 and 1.0, but no matter the Z values for my vertices, I still can't see my box.

This is becoming less of a concern for me, there're other aspects I can work on before really needing to render. I'm just curious though, what tipped you off that this code was pre DirectX9?

m_pD3DDevice->SetVertexShader(D3DFVF_CUSTOMVERTEX);

That did.

Ah, I see. As opposed to the SetFVF() method. I was hoping it was going to be the Orthogonal Camera setup.

I've been messing around with DX9 since the beginning of this thread. And it's.....very similar. The only troubles I'm really having now are finding a way to actually set up an Orthogonal Projection matrix. Other than DrunkenHyena, I haven't been able to find many in-depth tutorials on DX9.

So far my two options as I see it are:
1) Figure out this Orthogonal Projection (which I'm hoping will be similar enough to DX8 that I can just code it in that way and fix any minor discrepancies as they show up.)

2) Use DrawPrimitiveUP(). I have, let's call them "Floaties". One Floaty consists of 4 vertices. I will be drawing 2 Million Floaties on screen, each with their own position and speed. So each frame I must update each and every Floaty.
To use DrawPrimitiveUP(), do I just adjust the vertice X, Y values, and call DrawPrimitiveUP (essentially the only thing I'm leaving out is locking/unlocking)?

Speed/efficienty is taking precedence (spelling?) over simplicity.

Quote:

---

Originally Posted by Epo

Ah, I see. As opposed to the SetFVF() method. I was hoping it was going to be the Orthogonal Camera setup.

I've been messing around with DX9 since the beginning of this thread. And it's.....very similar. The only troubles I'm really having now are finding a way to actually set up an Orthogonal Projection matrix. Other than DrunkenHyena, I haven't been able to find many in-depth tutorials on DX9.

So far my two options as I see it are:
1) Figure out this Orthogonal Projection (which I'm hoping will be similar enough to DX8 that I can just code it in that way and fix any minor discrepancies as they show up.)

2) Use DrawPrimitiveUP(). I have, let's call them "Floaties". One Floaty consists of 4 vertices. I will be drawing 2 Million Floaties on screen, each with their own position and speed. So each frame I must update each and every Floaty.
To use DrawPrimitiveUP(), do I just adjust the vertice X, Y values, and call DrawPrimitiveUP (essentially the only thing I'm leaving out is locking/unlocking)?

Speed/efficienty is taking precedence (spelling?) over simplicity.

---

Maybe if you posted the whole project we could help more? Just a thought.

The ortho-projection matrix is described in the SDK Help file on the page for D3DXMatrixOrthoLH. There are also off-center matrices and their RH counter-parts.

DrawPrimitive(U)ser(P)ointer. Yes, you will not be locking/unlocking this. You simply manipulate your own array or what not and then you send that directly to DrawPrimitiveUP. This is slower than using vertex buffers but maybe it won't be significant for you.

Quote:

---

This is slower than using vertex buffers but maybe it won't be significant for you.

---

Not when your vertices are lower than about 100. If the number is less than 100 then internally Direct3D turns DrawPrimitiveUP into a DrawPrimitive call. In fact gamedev and beyond3d both recommend using DrawPrimitiveUP on batches of less than 100.

Using DrawPrimitiveUP on small batches is faster than continually locking/unlocking vertex buffers.


Ideally you want to use a huge indexed vertex buffer and simply give your object a certain range of those indices to use - same for textures. Specify a huge texture and index into it with your u,v coords for the correct texture.

This is akin to the old days when they used tiled bitmaps to represent all animation frames and simply indexed into the bitmap to extract the correct image.

Incidentally try this instead of what you are using.

Code:

---


class Object2D
{
  ID3DXSprite *m_pSprite;
  IDirect3DTexture9 *m_pTexture;
  IDirect3DDevice9 *m_pDevice;
 
  D3DXVECTOR3 m_pPos;
  float m_fScale;
  public:
          Object2D(void):m_pSprite(NULL),m_pTexture(NULL),m_pDevice(NULL),m_pPos(D3DXVECTOR3(0.0f,0.0f,0.0f)) {}
          ~Object2D(void)
          {
                SAFE_RELEASE(m_pTexture);
                SAFE_RELEASE(m_pSprite);
          }
         
          void Create(IDirect3DDevice9 *_device,float _scale,D3DXVECTOR3 _pos,std::string _file)
        {
          m_pDevice=_device;
          m_fScale=_scale;
          m_pPos=_pos;
 
          //Load texture
          D3DXCreateTextureFromFile(m_pDevice,_file.c_str(),&m_pTexture);
 
          //Create Sprite interface
          D3DXCreateSprite(m_pDevice,&m_pSprite);
        }
 
        void UpdateAndDraw(void)
        {
          D3DXMATRIX trans;
          D3DXMATRIX scale;
          D3DXMATRIX world;
         
          //Translation
          D3DXMatrixTranslation(&trans,m_pPos.x,m_pPos.y,m_pPos.z);
 
          //Scaling
          D3DXMatrixScaling(&scale,m_fScale,m_fScale,1.0f);
 
          //Concatenate
          world=scale*trans;
 
          //Set transform
          m_pSprite->SetTransform(&world);
 
          //Draw sprite
          m_pSprite->Begin(D3DXSPRITE_ALPHABLEND);
 
          m_pSprite->Draw(Texture,NULL,NULL,NULL,0xFFFFFFFF);
 
          m_pSprite->End();
        }
};

---

ID3DXSprite is much easier than creating your own class that pretty much does the same thing. I'm changing all the billboarding code and sprite code in both of my games to use ID3DXSprite.

Okay, well here's a gist of the game:
If anyone's ever played Evolve (or Evolite), it's an oldschool game from way back in the day, you'll get what's happening.

Each player sets conditions for their organisms. (I.e., if two friends are beside you, go straight. If one enemy and one friend are beside you, turn left. And so forth.) Organisms multiply from eating food, or die if surrounded by too many enemies. (Something like the Game of Life, but not quite). Otherwise, the organisms are lemmingly travelling across the screen in their direction.

Now, each organism is just a square (4 vertices, width/height of 8 pixels.) With no overlap, the maximum amount of organisms that can fit in the screen are 20480.

1280 x 1024 = 1310720 Pixels
8 x 8 = 64 Pixels per Organism, 1310720 / 64 = 20480 Organisms

(The reason for 2 Million before was a resolution of 1600x1200 and one pixel per organism. But that would be impractical and very ugly.)

Though this will never be the case, I have to work with some number, and 20480 works. Since each organism has it's own velocity, I'll be needing to render each one every frame.

This Sprite method is looking promising, though I don't quite get what float _scale should be passed, nor where the actual size of the sprite gets declared. (And does UpdateAndDraw() fall inside of the D3DDevice->BeginScene() and D3DDevice->EndScene() methods? I'm hoping so, if I've learned anything about DX). :)




Thanks alot so far for the pointers so far Mr. Wizard and Bubba. I've been using DirectX for a long time, yet I still feel that I'm very near the beginning of it. There's so much to it that it's tough to wrap my head around everything the first time. (Or second, or third, or tenth).

Scale is used to scale the final vertices. When you pass in the IDirect3DTexture9 interface to ID3DXSprite it auto-computes the size of the quad based on the size of your texture.

D3DSURFACE_DESC _pDesc;

Texture->GetLevelDesc(0,&_pDesc);

float Width=(float)_pDesc.Width;
float Height=(float)_pDesc.Height;

Incidentally you must retrieve these values in order to correctly rotate sprites. ID3DXSprite assumes all sprites start in the upper left corner so you must offset their position by -Width*0.5f and -Height*0.5f.

These values can also be used for Bounding box computation on your sprite.

You must call ID3DXSprite::Begin(DWORD flags) prior to drawing any sprites.
You must draw between a Begin() and End() block.
You must clal ID3DXSprite::End() after you are done or prior to IDirect3DDevice9::EndScene().

Hm, I'm getting an obscene amount of linker errors when trying to compile.

Includes:

Code:

---

#include <D3D9.h>
#include <D3DX9CORE.h>

#pragma comment(lib, "D3D9.lib")
#pragma comment(lib, "D3DX9.lib")

---

Is there something that I'm missing?

And I'm still a little unsure about the scaling. Does that refer to the scaling of my screen? (I.e. Pass Width/Height) Or the scaling of the Texture in relation to the Screen (I.e. 1 to 1)?

EDIT: Since I'm linking the D3DX9.lib, I decided it a good idea o include D3DX9.h, but still, many many linking errors.

If you are compiling under MSVC for DirectX 9.0 Summer 2004 SDK + -> you MUST have 2 things.

1. The d3dx9.lib library file - it's in the summer 2004 extras.
2. BASETSD.H - this has not been included with the most recent DirectX SDKs. It defines several standard data types for MSVC. MS ASSumes we are developing using their super uber cool .NET neato frito garbage and so have dropped support for MSVC 6. But most people are NOT developing on .NET because it doesn't offer anything new for games and the upgrade doesn't really relate as far as graphics and games are concerned.

BASETSD.h is available on this site in the build errors thread, or you can get it inside of the Platform SDK.

My SDK Version is 9.0 (October 2004) Release.

The D3DX9.lib is in the "\Lib\" Folder.

BASETSD.h was not in the "\Include\" folder, but after creating a new Text Doc, pasting the code, and resaving as basetsd.h, I am still getting the same errors.

An example of a few:

Code:

---

Linking...
D3DX9.lib(cshaderprogram.obj) : error LNK2001: unresolved external symbol ___security_cookie
D3DX9.lib(cpslegacyprogram.obj) : error LNK2001: unresolved external symbol ___security_cookie
D3DX9.lib(cpsprogram.obj) : error LNK2001: unresolved external symbol ___security_cookie
D3DX9.lib(cvsprogram.obj) : error LNK2001: unresolved external symbol ___security_cookie
D3DX9.lib(cfxlprogram.obj) : error LNK2001: unresolved external symbol ___security_cookie

---

And you are positive you are linking with the MSVC 6 version of d3dx9.lib?

Those are all D3DX library errors. Double check which library you are linking to. Double check that you are not pointing MSVC to another library prior to the one you want. In other words make the DirectX library directory the FIRST one on the list - otherwise it wont find the files correctly. Same for includes.

Hm, I could've sworn I did it properly (I followed DrunkenHyena's setup instructions as best I could).

Tools->Options->Directories Tab

In the "Include files" dropdown I get these in the "Directories Listbox":
C:\Program Files\Microsoft DirectX 9.0 SDK (October 2004)\Include
C:\DXSDK\include
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE

And in the "Library files" dropdown I have these listed as Directories:
C:\Program Files\Microsoft DirectX 9.0 SDK (October 2004)\Lib
C:\DXSDK\Lib
C:\Program Files\Microsoft Visual Studio\VC98\LIB
C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB

Should I remove the DXSDK (They're the DX8 SDK Information Files), but my understanding was that it just searched form the top of the list down until it found what it needed.


It's not a problem that I'm Including/Linking the same files in two seperate headers is it?
My cD3D.h header has:

Code:

---

#include <Windows.h>
#include <D3D9.h>
#include "cORGANISM.h"

#pragma comment(lib, "D3D9.lib")

---

And my cORGANISM.h header has:

Code:

---

#include <D3D9.h>
#include <D3DX9.h>
#include <D3DX9CORE.h>

#pragma comment(lib, "D3D9.lib")
#pragma comment(lib, "D3DX9.lib")

---

Thanks for all the suggestions so far though. I'm sure that basetsd.h would've come into play in the near future too.

If you include d3dx9.h and link with d3dx9.lib you DO NOT need to include d3dx9core.h AFAIK. I believe that d3dx9.h acts as a do-it-all header and included the appropriate DirectX headers for those functions for which it makes use of. Now of course if you want DirectInput, DirectMusic, etc, you must include the correct header. But not for use of the D3DX library. The whole thing should be in d3dx9.h

Okie dokes, well I've removed the D3DX9CORE.h file.

Without the:
#pragma comment(lib, "D3DX9.lib")

I get:

Code:

---

Linking...
cORGANISM.obj : error LNK2001: unresolved external symbol _D3DXCreateSprite@8
cORGANISM.obj : error LNK2001: unresolved external symbol _D3DXCreateTextureFromFileA@12
cORGANISM.obj : error LNK2001: unresolved external symbol _D3DXMatrixScaling@16
cORGANISM.obj : error LNK2001: unresolved external symbol _D3DXMatrixTranslation@16
cORGANISM.obj : error LNK2001: unresolved external symbol _D3DXMatrixMultiply@12
Debug/Evolve.exe : fatal error LNK1120: 5 unresolved externals

---

But MSDN tells me that D3DX9.lib is the import library for all of those. So I toss it in, and that's where I get, instead, 67 errors.

I'm running out of ideas. Maybe I have a faulty D3DX9.lib file? I don't know.

I'll just keep messing around with it, and if I stumble on the answer, I'll let you know so's the next person that hits this ridiculous problem doesn't have a heart attack as well.

You are simply not linking with d3dx9.lib. That can be the only thing leading to those errors. Either MSVC 6 is not finding it correctly or you are missing something when you are specifying where it is. Basically the headers are now ok and you have no errors relating to headers that I can see. Your problem is d3dx9.lib.

You may also want to try and re-create your entire project in another folder. Sometimes projects get fragged under MSVC. You may also want to try and do a clean, and rebuild entire project. Something's amiss somewhere.

Please post screenshots of your build environment, the code that is failing or the code that uses the functions that are not being linked in correctly, the project window for both includes, source, and for dependencies - this will show all external dependencies like the d3dx9.lib library functions. Also it would be helpful for you to post a screenshot of the class view and anything else you may think relevant to the problem.

This is really the only way I can help short of taking control of your system via remote connection on MSN messenger and diagnosing/troubleshooting it myself.

Also if you have the teamspeak client, I can fire up my teamspeak server and we can discuss and troubleshoot the problem together while on remote connection. Of course you will need speakers and a microphone and the client. Google for teamspeak RC2 client and it will find it. I won't spam the link here.

Okay, well I've put together all that I think you mentioned and a few extras that, just in case, might come in handy.

I was restricted by the size of the attachments so I included the source files.

I doubt it's working like it should. I was hoping to troubleshoot as I went, but, well, I can't without it actually running. :)

Each time before I run, I re-build all. I also re-created the project in a seperate directory, but the same errors kept coming up.

I really appreciate you taking all this time, I just have no clue where to go from here. (If it ends up to be a missing semi-colon, I will cry.)

(And I think I'll invest in a microphone in the near future). :)

The code compiled fine on my machine with 0 errors and 0 warnings.

Here is the link information:

Note that even when I left out d3d9.lib, dxguid.lib, and winmm.lib it still compiled fine. However it does absolutely nothing but attempt to fire up Direct3D and then quickly return to the desktop.

Here is the include info:

And the library info:

Everything is nearly identical to what you have sent me. Perhaps the second reference to another version of the SDK is causing the problem.

Remove the reference to the second version of the SDK (DXSDK/*.*) in both the library and include options. Perhaps it is double-linking or doing something weird.

Hm, it wasn't the double-linking. I didn't realize there was still more info, and comparing my picture to yours, I'm obviously missing all my libraries from the Project Options.

I wasn't aware I had to manually add them in.

Update: After trying it out, since you mentioned you didn't really need the other Libs there, I only added "d3dx9.lib" to the beginning of them all. Only one error:
Linking...
LINK : fatal error LNK1104: cannot open file "d3dx9.lib,"
Error executing link.exe.

I don't know if this is better or worse :)

EDIT: And I'm a big idiot :) (Notice the comma in the error). Well, without the comma, I'm back up to 67 errors.

I'll toss in the rest of the Libs, see what happens. If all else fails, I'll try and find a copy of the Summer SDK, maybe October was just a bit too soon for Microsoft's next release.

I may have found it...

Taken from the "About DirectX9.0 SDK" section off the October Release's "CD"

Code:

---

D3DX

Issues:
In order to use Visual C 6.0 with D3DX you need to link with the D3DX that is located in the
extras directory at the location: Extras\D3dx Visual Studio 6\d3dx9.lib. In the future,
support for Visual Studio 6 may not be continued.

---

I guess I should link there no? :)

EDIT:
Okay, so that folder definitely does not exist on my machine.

I did a complete re-install of DX, still the same.

I've said from the beginning that you must have these for DX to work with MSVC:

1. The D3DX9.lib located in the Extras folder of the SDK installation - this is the msvc version. Simply rename the current lib in the lib folder d3dx9-net.lib or something like it.
2. The BASETSD.h include file found in the Platform SDK.

This is a quote from this very thread.

Quote:

---

12-07-2004, 07:07 AM If you are compiling under MSVC for DirectX 9.0 Summer 2004 SDK + -> you MUST have 2 things.

1. The d3dx9.lib library file - it's in the summer 2004 extras.
2. BASETSD.H - this has not been included with the most recent DirectX SDKs. It defines several standard data types for MSVC. MS ASSumes we are developing using their super uber cool .NET neato frito garbage and so have dropped support for MSVC 6. But most people are NOT developing on .NET because it doesn't offer anything new for games and the upgrade doesn't really relate as far as graphics and games are concerned.

BASETSD.h is available on this site in the build errors thread, or you can get it inside of the Platform SDK.

---

Sorry Bubba, that was my mis-interpretation. I'm using the October release, so I just assumed that the D3DX9.Lib that was already in my Lib folder was that same one, since there isn't an actual "Extras" folder with this release. There is an x64 folder. No clue what that means, but there's a D3DX9.Lib in there.

For simplicity, I'll find a version of the Summer release and install that one instead. Hopefully that'll straighten some things out.

Thanks again Bubba.