Jump to content

  • Log In with Google      Sign In   
  • Create Account


GameCodingNinja

Member Since 18 Aug 2005
Offline Last Active Feb 21 2014 12:06 AM
-----

Topics I've Started

No window frame when going from full screen back to windowed mode

06 January 2013 - 05:35 PM

I have read through tons of post here on this subject and looked at numerous code examples and for the life of me, I can't get this to work correctly. As far as I can tell, I'm not doing anything different then what I have been seeing.

 

I start out in windowed mode and then change it to full screen mode and then change it back to windowed mode. Even though I'm resetting the styles via "SetWindowLong" and then calling "SetWindowPos", I'm left with a window with no window frame.

 

I've tested this ever way I can think of. Any idea of what I might be missing?

 

I define the styles in the constructor as class members...

CXWindow::CXWindow() :
...
windowedStyle(WS_OVERLAPPED|WS_SYSMENU|WS_MINIMIZEBOX),
windowedExStyle(WS_EX_APPWINDOW|WS_EX_WINDOWEDGE),
fullScreenStyle(WS_POPUP|WS_VISIBLE),
fullScreenExStyle(WS_EX_TOPMOST)

 

This is how I create the window.

void CXWindow::CreateXWindow( const HINSTANCE hInst )
{
    uint dwExStyle;
    uint dwStyle;

	RECT rect;

	// Set the rect
    SetRect( &rect, 0, 0, (int)CSettings::Instance().GetSize().w, (int)CSettings::Instance().GetSize().h );

    if( CSettings::Instance().GetFullScreen() )
    {
        dwExStyle = fullScreenExStyle;
        dwStyle = fullScreenStyle;
    }
	else
    {       
        // Setup the styles
        dwExStyle = windowedExStyle;
        dwStyle = windowedStyle;   
    }
    
    // Create the window
    hWnd = CreateWindowEx( dwExStyle,
						   CSettings::Instance().GetGameWndClassName().c_str(),
						   "",
                           dwStyle,
						   rect.left,
						   rect.top,
                           rect.right,
						   rect.bottom,
                           NULL,
						   NULL,
						   hInst,
						   NULL );

	if( hWnd == NULL )
		throw NExcept::CCriticalException("Create Window Error",
			boost::str( boost::format("There was an error creating the game window.\n\n%s\nLine: %s") % __FUNCTION__ % __LINE__ ));

	if( !CSettings::Instance().GetFullScreen() )
	{
		// Adjust the rect so that the client size of the window is the exact size of the needed resolution
		AdjustWindowRectEx( &rect, GetWindowStyle(hWnd), GetMenu(hWnd) != NULL, GetWindowExStyle(hWnd) );

		// Position the window in the center of the screen
		SetWindowPos( hWnd,
					  HWND_NOTOPMOST,
					  (GetSystemMetrics( SM_CXSCREEN ) - (rect.right-rect.left)) / 2, 
					  (GetSystemMetrics( SM_CYSCREEN ) - (rect.bottom-rect.top)) / 2,
					  rect.right - rect.left,
					  rect.bottom - rect.top,
					  SWP_NOACTIVATE );
	}

}   // CreateXWindow

 

I call this prior to resetting the DirectX device. I've even recalled it after the device was reset.

void CXWindow::ResetWindowStyle()
{
	if( CSettings::Instance().WasScreenModeChanged() )
	{
		uint dwExStyle = windowedExStyle;
		uint dwStyle = windowedStyle;

		if( CSettings::Instance().GetFullScreen() )
		{
			dwExStyle = fullScreenExStyle;
			dwStyle = fullScreenStyle;
		}

		// Change the windows styles
		SetWindowLong( hWnd, GWL_STYLE, dwStyle);
		SetWindowLong( hWnd, GWL_EXSTYLE, dwExStyle);
	}

}	// ResetWindowStyle

 

This is what I call after the device reset. One odd thing to note is that in this function, "AdjustWindowRectEx" does not change the rect like it does when the window was first created. The rect remains unchanged.

void CXWindow::ResetWindowSize()
{
RECT rect;

	// Set the rect
    SetRect( &rect, 0, 0, (int)CSettings::Instance().GetSizeChange().w, (int)CSettings::Instance().GetSizeChange().h );

	if( CSettings::Instance().WasResolutionChanged() || CSettings::Instance().WasScreenModeChanged() )
	{
		if( CSettings::Instance().WasResolutionChanged() )
		{
			// Recalculate the default size and ratio
			CSettings::Instance().CalcRatio( CSettings::Instance().GetSizeChange() );

			// Recalculate the projection matrixes
			CalcProjMatrix( CSettings::Instance().GetSizeChange(),
							CSettings::Instance().GetDefaultSize() );
		}

		if( !CSettings::Instance().WasScreenModeChanged() )
		{
			// Adjust the rect so that the client size of the window is the exact size of the needed resolution
			AdjustWindowRectEx( &rect, GetWindowStyle(hWnd), GetMenu(hWnd) != NULL, GetWindowExStyle(hWnd) );

			// Position the window in the center of the screen
			SetWindowPos( hWnd,
						  HWND_TOP,
						  (GetSystemMetrics( SM_CXSCREEN ) - (rect.right-rect.left)) / 2, 
						  (GetSystemMetrics( SM_CYSCREEN ) - (rect.bottom-rect.top)) / 2,
						  rect.right - rect.left,
						  rect.bottom - rect.top,
						  SWP_FRAMECHANGED|SWP_SHOWWINDOW );
		}
	}

}	// ResetWindow

ChangeDisplaySettings causing threads to dead lock

02 December 2012 - 09:43 AM

I think my threads are becoming dead locked... this is what's happening.

I create a thread and a mutex to load assets in the startup game state while display a startup graphic. It all works great. No problems unless I change the resolution to full screen the game for a different resolution. Windowed mode or full screen of same resolution all works fine.

I call ChangeDisplaySettings before creating the game window and DirectX.

I'm not sure what to make of this and I tried some work arounds but it seems like the threads get stuck at WaitForSingleObject. At least that's what it seems like.

Any suggestions?

What to do when you get an error

30 October 2012 - 06:38 AM

I'm writing a TCP client/server Boost::asio wrapper.

Say I get an error during a send or receive. The simple thing to do would be to drop the connection. I guess if I get an error during a send, I could try a few more times before I drop the connection. Would that be the logical way to handle a send error?

Say I get an error during a "receive". Since we are talking TCP, I'm not sure how I would re-sync with the client or server since the received data can be part of a message or a combination of many. Perhaps send a message that indicates an error has happened so stop sending data and re-sync messages.

Would that be a proper way to handle errors?

winsocket overlapped i/o question

25 October 2012 - 07:58 AM

With the the overlapped i/o model, do you still need parse the received data because what is received can be a partial or a mixture of multiple sends?

A simple networking question

15 October 2012 - 09:40 AM

I've just started learning winsockets.

When my client computer attempts to connect to a server, I'm assuming it has picked a port to tell the server it can use to communicate back. Is this a standard port or a random one?

Thanks!

PARTNERS