Can the mesh viewer in the SDK open your .X file?
What's changed in your program since the last version?

Yes DXViewer can open my mesh with textures and everything. All I've changed is that I've added HLSL and removed the SetRenderState functions and changed SetTransform to the effect's SetMatrix function.

I've never used the debug function in VS2008 before so now I noticed I get:

Direct3D9: (WARN) :Ignoring redundant SetSamplerState Sampler: 0, State: 29
And it's a lot more numbers than 29. I've searched and found some that say it's because I don't use a "pure" device (which I don't know what that is). Does it decrease the performance of the program?

Also, I get some error each time I shut down the program:

Debug Assertion Failed!
...
_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

and then the debug says:

Direct3D9: (ERROR) :GetClientRect Failed ?
Direct3D9: (ERROR) :GetClientRect Failed ?
Direct3D9: (ERROR) :BitBlt or StretchBlt failed in Present

Since other meshes (which has textures) is being rendered in my program I am pretty sure I've somehow messed something up (even though the mesh + textures that don't work are in the same folder + DXViewer can render it without any problem) so I guess I'd better fix these other problems.

EDIT: My Present function looks like this:
pD3DDev->Present(0, 0, 0, 0);

Which has been left unchanged for ages.

Quote:Original post by Hannesnisula
I've never used the debug function in VS2008 before so now I noticed I get:

Direct3D9: (WARN) :Ignoring redundant SetSamplerState Sampler: 0, State: 29
And it's a lot more numbers than 29. I've searched and found some that say it's because I don't use a "pure" device (which I don't know what that is). Does it decrease the performance of the program?

It just means that you're calling SetRenderState() with a state that's already set, so it's a redundant change. If you have a pure device then it's more expensive, but if you don't have a pure device, D3D will filter redundant changes for you.
A pure device is a device created with the D3DCREATE_PUREDEVICE flag. From the Documentation:
Specifies that Direct3D does not support Get* calls for anything that can be stored in state blocks. It also tells Direct3D not to provide any emulation services for vertex processing. This means that if the device does not support vertex processing, then the application can use only post-transformed vertices.
There's also a bit in the FAQ under "What is the purpose of the D3DCREATE_PUREDEVICE flag?".

Quote:Original post by Hannesnisula
Also, I get some error each time I shut down the program:

Debug Assertion Failed!
...
_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

You have some heap corruption going on, usually caused by deleting a pointer twice, or using a pointer after it's been deleted. That's not D3D related, it refers to one of your new[]'d pointers.

Quote:Original post by Hannesnisula
Direct3D9: (ERROR) :GetClientRect Failed ?
Direct3D9: (ERROR) :GetClientRect Failed ?
Direct3D9: (ERROR) :BitBlt or StretchBlt failed in Present

That's usually caused by killing your window before D3D - D3D is still trying to render, but the window has been destroyed. Check that you're not destroying your window (Processing WM_DESTROY) while D3D is still active.

Thank you so much! Evil Steve for president :D

EDIT: Forgot to ask something >.< I don't use the D3D Device's SetRenderState() but I do set mipfilter etc in my sampler in my HLSL shader. Could that cause the problem? Then how can I change the render state to anything else without doing redundant changes?

Quote:Original post by Hannesnisula
Thank you so much! Evil Steve for president :D

EDIT: Forgot to ask something >.< I don't use the D3D Device's SetRenderState() but I do set mipfilter etc in my sampler in my HLSL shader. Could that cause the problem? Then how can I change the render state to anything else without doing redundant changes?

I gather that the effects framework makes a lot of redundant state changes. Short of changing to a different system I don't think there's much you can do.
It's not really much of a problem to be honest, if it annoys you too much, just turn the debug output level down a notch [smile]

Oh, I just thought it was a huge performance decrease. So if you're using HLSL with samplers that set states, you're worse off with a pure device, right?

Quote:Original post by Hannesnisula
Oh, I just thought it was a huge performance decrease. So if you're using HLSL with samplers that set states, you're worse off with a pure device, right?

Probably, but it'll be a very small performance drop. If you're worried about it, try profiling with and without a pure device and see if there's any difference.