my app's only drawing parts of what has to be drawn

Recommended Posts

Hello, Each time I start my game only parts of what has to be drawn are actually drawn. The rest is empty, the colour of which I cleared the screen with. And the strange thing is...each time I use my N64 emulator, or the screensaver is used...the parts that are drawn change. These are some of the screens I got: Off course that's not what it's supposed to be. It's a 3d room with brown and grey tiles. But you can't see that ;). At one time I could really see a part of the floor, but the above pic doesn't resemble anything at all. Does anyone have an idea what the problem could be? -Stenny

Share on other sites
Quote:
 Original post by stennyEach time I start my game only parts of what has to be drawn are actually drawn. The rest is empty, the colour of which I cleared the screen with. And the strange thing is...each time I use my N64 emulator, or the screensaver is used...the parts that are drawn change.

Are you clearing all the needed buffers correctly (z/depth buffer, target buffer)? This might explain why the drawn parts change when you run other applications.

JFF

Share on other sites
Are you clearing the Z-Buffer every frame?

Share on other sites
I'm not using a ZBuffer, but I'll have a look at my display clear function.

-Stenny

EDIT

Ok I normally use this function:

BOOL cGraphics::ClearDisplay(long Color)
{
if(m_pD3DDevice == NULL) {
return FALSE;
}
if(FAILED(m_pD3DDevice->Clear(0, NULL, D3DCLEAR_TARGET, Color, 1.0f, 0))) {
return FALSE;
}

return TRUE;
}

But when I tried this one:

BOOL cGraphics::Clear(long Color, float ZBuffer)
{
if(m_pD3DDevice == NULL) { return FALSE; }
if(m_ZBuffer == FALSE) { return ClearDisplay(Color); }
if(FAILED(m_pD3DDevice->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, Color, ZBuffer, 0))) { return FALSE; }

return TRUE;
}

it works better. Now it looks like this:

-Stenny

Share on other sites
Quote:
 Original post by stennyI'm not using a ZBuffer, but I'll have a look at my display clear function.

If you're not using it, make sure you are turning it off using D3DRS_ZENABLE.

Share on other sites
I've sort off had the same issue, make sure you clear all the buffers you create.

Share on other sites
Ok. Here goes:

1) I call function BOOL cGraphics::SetMode(HWND hWnd, BOOL Windowed, BOOL UseZBuffer, long Width, long Height, char BPP) with this: m_Graphics.SetMode(GethWnd(), TRUE, FALSE);

2) In side SetMode() is this piece of code:

if((m_ZBuffer = UseZBuffer) == TRUE){	d3dpp.EnableAutoDepthStencil	= TRUE;	d3dpp.AutoDepthStencilFormat	= D3DFMT_D16;} else {	d3dpp.EnableAutoDepthStencil	= FALSE;}

When I check with Intellisense, EnableAutoDepthStencil ánd m_ZBuffer are both 0.

3) I give a call to ClearDisplay() with the code in my above post.

As far as a I know I don't use any buffers except for D3DCLEAR_TARGET, which I Clear...

-Stenny

[Edited by - stenny on October 18, 2006 2:43:23 PM]

Share on other sites
Take a look at this.

I think you should do like them but disabling the z-bufferring instead.

   presParams.EnableAutoDepthStencil = FALSE;

Then create the device with those presentation parameters. Next step would be to disable Z-buffer.

   // Turn on the zbuffer   gD3dDevice->SetRenderState( D3DRS_ZENABLE, D3DZB_FALSE );

Then clearing the Z-buffer will not be relevant but I'd do it anyway just to be sure (and remove it if it was really a performance problem).

   gD3dDevice->Clear(0,NULL,D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER,D3DCOLOR_XRGB(255,255,255),1.0f,0);

Share on other sites
with that last image, it looks like you are staring at the farplane..how large is your geometry?

Share on other sites
well I haven't even covered farplanes or frustrum thinging (or whatever it's called). The geometry consists of 8 meshes; 4 corridors and 4 rooms. I don't know how big exactly these meshes are because I got them from my book, but I guess a room's about 2000x2000x1500?

I don't really see why you asked though, since you don't really measure wíth anything in 3D. it could be 2000 metres but also 2000 miles, 2000 micrometers or 2000 inches.

-Stenny

Share on other sites
It's true that units of measurement can be whatever you want them to be when you make your game, but there are the 'units' of measurement that define object's height and width and whatnot.

When you use a Z-Buffer, you set whatever distance that is far away is 1.0, and whatever distance that is close is 0.0, the near plane and far plane. Each pixel is then placed within that range, and either drawn or discarded whether or not it is front. You can set the far plane to be 100 or 1000 or whatever, and the near plane to anything that isn't zero.

What's happening there is that the pixels in that black area are at a distance of 1.X, and is thusly failing the Z-Test. You'll need to extend out your far plane to include the rest of your geometry.

Share on other sites
The only problem is that, as I've already said, aren't using a ZBuffer. At least, not that I know.

-Stenny

Share on other sites
This is being clipped by the far plane of the viewing frustum - not the depth buffer. This far plane is typically specified when you create the projection matrix.

Share on other sites
Thanks, that sounds pretty logical. I'll try it and edit :).

-Stenny

Create an account

Register a new account

• Forum Statistics

• Total Topics
627708
• Total Posts
2978732

• 21
• 14
• 12
• 22
• 35