Cheat Engine

oib111 · Posted: Sun Jul 26, 2009 9:14 am Post subject: Z-buffer and Culling in DirectX

I'm trying to draw two triangles, one behind the other so I'm using the Z-buffer. I'm using this tutorial. I noticed in his source code he turned off culling even though he didn't mention anything about that in the tutorial. So why do you have to turn of culling when you're using the Z-buffer?

HolyBlah · Posted: Sun Jul 26, 2009 10:42 am Post subject:

He does that so you can see the triangles from both sides. he explains that in lesson 5 table 5.1.

oib111 · Posted: Sun Jul 26, 2009 1:44 pm Post subject:

You aren't trying to look at the triangles from both sides though?

HolyBlah · Posted: Sun Jul 26, 2009 4:32 pm Post subject:

You must see the triangles from both sides to see the effect of z-buffer.
If you won't turn cullmode off you won't be able to see the effect while the
triangles with their "back" to the camera.

oib111 · Posted: Sun Jul 26, 2009 5:18 pm Post subject:

Oh, thanks. That makes sense Smile

hcavolsdsadgadsg · Posted: Sun Jul 26, 2009 5:29 pm Post subject:

The common cullmode in DX is to cull away counter clockwise facing verts. (as such, you should take caution to always create them clockwise)

As such, when you create your triangle, you'll probably be looking directly at it until you move it or the camera. If you have culling enabled, there is no backside to the triangle.

I'm pretty sure culling is disabled by default, though.

edit: also this is a MUCH better site than Directxtutorial.com, which doesn't do any error checking and has some noticeable bad practices (trying to keep track of the framerate with GetTickCount(), really?)

http://thetavern.servebeer.com/?p=articles

oib111 · Posted: Sun Jul 26, 2009 7:39 pm Post subject:

Isn't D3DRS_CULLMODE set to D3DCULL_CCW by default? Also, I'll look at that site after dinner. Thanks Smile

tombana · Posted: Mon Jul 27, 2009 1:37 pm Post subject:

hcavolsdsadgadsg · Posted: Mon Jul 27, 2009 4:00 pm Post subject:

It is (assuming you set it to 1ms with timeBegin / EndPeriod) but you may still have problems with it.

60 fps is 16.667 ms to render the frame.
100 fps is 10 ms...
250 fps is 4 ms...
1000 fps is 1 ms...

If your FPS ever dares to go over 1000, your timing code is going to end up completely breaking... Quake 3 for example uses timeGetTime if I remember right and it does in fact shit itself when your FPS starts to get very high.

This is where QueryPerformanceCounter() comes in... or I guess you could use rdtsc, but I don't think this always works correctly on multi-core systems? maybe someone else can comment on this