Jump to content
  • Advertisement
Sign in to follow this  
v0dKA

Windowed VS Not Windowed - Major Speed Differences

This topic is 4968 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Why is my windowed Direct3D so much faster than full screen? I have a triangle that rotates around on the screen. In the time it takes the triangle to rotate once fullscreen, it must have rotated 10 times in windowed mode. Here's the initialization code for both modes:
////////////////////////////////
// InitWindowed()
////////////////////////////////
BOOL InitWindowed( D3DPRESENT_PARAMETERS* D3DPresentParams )
{
	D3DDISPLAYMODE display;
	HRESULT hResult = g_pDirect3D->GetAdapterDisplayMode(
		D3DADAPTER_DEFAULT, &display );
	if( hResult != D3D_OK )
		return FALSE;

	D3DPresentParams->Windowed = TRUE;
	D3DPresentParams->BackBufferFormat = display.Format;
	D3DPresentParams->SwapEffect = D3DSWAPEFFECT_DISCARD;
	D3DPresentParams->hDeviceWindow = g_hWnd;
	D3DPresentParams->BackBufferCount = 1;

	return TRUE;
}

////////////////////////////////
// InitFullscreen()
////////////////////////////////
void InitFullscreen( D3DPRESENT_PARAMETERS* D3DPresentParams )
{
	D3DPresentParams->Windowed = FALSE;
	D3DPresentParams->BackBufferCount = 1;
	D3DPresentParams->BackBufferWidth = 1024;
	D3DPresentParams->BackBufferHeight = 768;
	D3DPresentParams->BackBufferFormat = D3DFMT_X8R8G8B8;
	D3DPresentParams->SwapEffect = D3DSWAPEFFECT_DISCARD;
	D3DPresentParams->hDeviceWindow = g_hWnd;
}

I use X8R8G8B8 for full screen no matter what the current format is on the graphics card. However, I did check what full screen mode would act like by using the same initialization as my windowed mode, but it doesn't make a difference. Is there a reason for this major speed difference? Here are a couple more relevant code snippets: Set up the vertex buffer, store vertices, etc:
////////////////////////////////
// Setup()
////////////////////////////////
BOOL Setup()
{
	g_pDevice->SetRenderState( D3DRS_LIGHTING, FALSE );
	g_pDevice->SetRenderState( D3DRS_CULLMODE, D3DCULL_NONE );

	HRESULT hResult = g_pDevice->CreateVertexBuffer( 3*sizeof(CUSTOMVERTEX),
		D3DUSAGE_WRITEONLY, MyFVF, D3DPOOL_MANAGED, &pVertexBuffer );
	if( FAILED( hResult ) )
	{
		DXTRACE_ERR( "Error creating vertex buffer", hResult );
		return FALSE;
	}

	VOID* pVertices;
	hResult = pVertexBuffer->Lock( 0, 0, (BYTE**)&pVertices, 0 );
	if( FAILED( hResult ) )
	{
		DXTRACE_ERR( "Error locking vertex buffer", hResult );
		return FALSE;
	}
	memcpy( pVertices, triangle, sizeof( triangle ) );
	pVertexBuffer->Unlock();

	g_pDevice->SetStreamSource( 0, pVertexBuffer, sizeof( CUSTOMVERTEX ) );
	g_pDevice->SetVertexShader( MyFVF );
	
	SetupWorld();

	return TRUE;
}

////////////////////////////////
// SetupWorld()
////////////////////////////////
void SetupWorld()
{
	D3DXMATRIX matView, matProj;

	D3DXMatrixScaling( &matScale, 5.0f, 5.0f, 5.0f );
	g_pDevice->SetTransform( D3DTS_WORLD, &matScale );

	D3DXMatrixLookAtLH( &matView,
		&D3DXVECTOR3( 0.0f, 0.0f, -15.0f ),		// Camera position
		&D3DXVECTOR3( 0.0f, 0.0f, 0.0f ),		// Look at position
		&D3DXVECTOR3( 0.0f, 1.0f, 0.0f ) );		// Up vector
	g_pDevice->SetTransform( D3DTS_VIEW, &matView );

	D3DXMatrixPerspectiveFovLH( &matProj,
		D3DX_PI / 4, 1.0f, 1.0f, 500.0f );
	g_pDevice->SetTransform( D3DTS_PROJECTION, &matProj );

	return;
}

Render function, called per frame:
////////////////////////////////
// Render()
////////////////////////////////
void Render()
{
	g_pDevice->Clear( 0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB( 0,0,0 ), 1.0f, 0 );
	g_pDevice->BeginScene();

	D3DXMATRIX matRotX;
	D3DXMATRIX matRotY;
	D3DXMATRIX matRotZ;
	g_iRotationFactor += 0.004f;
	D3DXMatrixRotationX( &matRotX, g_iRotationFactor );
	D3DXMatrixRotationY( &matRotY, g_iRotationFactor );
	D3DXMatrixRotationZ( &matRotZ, g_iRotationFactor );
	D3DXMatrixMultiply( &matWorld, &matRotY, &matRotZ );
	D3DXMatrixMultiply( &matWorld, &matWorld, &matRotX );
	D3DXMatrixMultiply( &matWorld, &matScale, &matWorld );
	g_pDevice->SetTransform( D3DTS_WORLD, &matWorld );

	g_pDevice->DrawPrimitive( D3DPT_TRIANGLELIST, 0, 1 );
	g_pDevice->EndScene();
	g_pDevice->Present( NULL, NULL, NULL, NULL );
}

Debug output is almost the same either way. Any insight on this would be appreciated.

Share this post


Link to post
Share on other sites
Advertisement
When you are in Fullscreen, the framerate is limited to the refresh rate. (60hz, 72hz, etc)

the easiest way to get around this is to impliment a timer function and limit your program to the framerate you want(usally 30fps), and for your polygon updates, use a function like:

newtime = Timer.GetCurrentTime();
if(newtime >= oldtime)
{
Do Stuff....
Update Poly....
oldtime = newtime + 30;
}

this will limit your poly to updating every 30 timer units(usally ms)

Share this post


Link to post
Share on other sites
Quote:
Original post by IndigoStallion
When you are in Fullscreen, the framerate is limited to the refresh rate. (60hz, 72hz, etc)

the easiest way to get around this is to impliment a timer function and limit your program to the framerate you want(usally 30fps), and for your polygon updates, use a function like:

newtime = Timer.GetCurrentTime();
if(newtime >= oldtime)
{
Do Stuff....
Update Poly....
oldtime = newtime + 30;
}

this will limit your poly to updating every 30 timer units(usally ms)

Never lock the framerate. Instead, give all movements in units / second, and then multiply them by the number of seconds passed between each frame.

Share this post


Link to post
Share on other sites
Does this frame rate apply to windowed, fullscreen, or both? Where should I implement the techniques you've shown?

Secondly, does this imply the triangle will rotate faster or slower?

Share this post


Link to post
Share on other sites
Quote:
Original post by IndigoStallion
When you are in Fullscreen, the framerate is limited to the refresh rate. (60hz, 72hz, etc)

the easiest way to get around this is to impliment a timer function and limit your program to the framerate you want(usally 30fps), and for your polygon updates, use a function like:

Actually, I think the easiest way to get around this is to simply disable it. You can do it by setting your

D3DPRESENT_PARAMETERS.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE

Right now, you aren't setting it at all, defaulting it to D3DPRESENT_INTERVAL_ONE.

Share this post


Link to post
Share on other sites
I agree, never lock the framerate, and if you do, don't make it some horribly low fps like 30. MAYBE after 100-150 fps if you have leftover time you could do some other things. Gamers notice 30fps and how bad it looks.

Share this post


Link to post
Share on other sites
I triple that. Gamers with good hardware should never have to suffer unnecessarily low framerates.

Quote:

Does this frame rate apply to windowed, fullscreen, or both? Where should I implement the techniques you've shown?

Both. Anything that changes over a period of time should use this technique. It allows for all objects to move at a constant speed regardless of framerate.

As for WHY your app runs faster in Windowed mode: It can partially be due to syncing with the refresh-rate, but possibly it could also be that your hardware was designed to work that way. Just another reason all movement should be time-based.

Share this post


Link to post
Share on other sites
Quote:
Original post by MasterWorks
I agree, never lock the framerate, and if you do, don't make it some horribly low fps like 30. MAYBE after 100-150 fps if you have leftover time you could do some other things. Gamers notice 30fps and how bad it looks.


Correct. With very high framerates, you can experience tearing (on some hardware), so it's not a bad idea to give the user an option to cap the framerate. With Valve's Source engine, it lets you set the specific rate.

Also, never just stall the CPU just to limit framerate (ie do a sleep()). Instead, continue onto other tasks, like AI, physics, ect... That way, the game is still being maintained - but it's just not rendering.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raloth
Never lock the framerate. Instead, give all movements in units / second, and then multiply them by the number of seconds passed between each frame.
Careful. You never lock the renderering framerate, sure, but lockstep game updates can make things like networking infinitely easier.

Share this post


Link to post
Share on other sites
I agree with the second solution of using units and checking how much time has passed.

But no one apparently meantioned WHY you have problems (no offense one person tried but I don't think it was too exact) when your in Windowed mode, your producing FAR fewer pixels and that means you get done rendering faster as well as problems with refresh rates. You have to limit your rendering in some way, and there's a bunch of suggestions in here)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!