gamedevlists-windows

RE: [GD-Windows] Messed up windows after fullscreen

[Brian H. <pu...@py...>]

> when you close the window, or exit the app, do you call
> 
> ChangeDisplaySettings(NULL,0)

Yes. And for those that are thinking of quoting the parallel thread on
the DX list, this is not using DDraw or D3D at all (OpenGL only).  So
it's something to do with the display settings.  I'll see if it does on
my WinME/i815 test machine.

Brian

RE: [GD-Windows] Messed up windows after fullscreen

[Brian H. <pu...@py...>]

That's basically what I'm doing.  My exact shutdown sequence is:

glDeleteLists( ... );
wglMakeCurrent( ... );
wglDeleteContext( ... );
SetDeviceGammaRamp( oldGamma );
ReleaseDC();
ChangeDisplaySettings( 0, 0 );
DestroyWindow();

I tried transposing the DestroyWindow and CDS calls, but that didn't fix
it.  However, it seems like the issue might have more to do with losing
the focus while in full screen.  I just reran my code, and everything
works fine UNLESS SOMETHING ELSE TAKES THE FOCUS.  The first time I ran,
I lost the focus to ICQ for some reason.  The second time I ran Windows
decided that my app wasn't the active one and instead made another
random window on top.  I have no idea how to get around this -- I've
tried SetFocus() and all the various permutations of topmost window,
etc. and it still randomly gives the focus to another running when I
start to run.

Brian

RE: [GD-Windows] Messed up windows after fullscreen

[Daniel V. <vo...@ep...>]

> random window on top.  I have no idea how to get around this -- I've
> tried SetFocus() and all the various permutations of topmost window,
> etc. and it still randomly gives the focus to another running when I
> start to run.

If I understood you correctly you want something like below:


// Bring window to the top (including all Win32 mojo).
HWND hWndForeground = ::GetForegroundWindow();

AttachThreadInput(GetWindowThreadProcessId(hWndForeground, NULL),
GetCurrentThreadId(), true);

SetForegroundWindow( Window->hWnd );
SetActiveWindow( Window->hWnd );

AttachThreadInput(GetWindowThreadProcessId(hWndForeground, NULL),
GetCurrentThreadId(), false);


- Daniel Vogel, Programmer, Epic Games Inc.

RE: [GD-Windows] Messed up windows after fullscreen

[Brian H. <pu...@py...>]

Hmmm, I wasn't using SetActiveWindow (I was using SetFocus -- could
Windows possibly provide enough variations on these?!).  Also, what's
the AttachThreadInput business all about?

Brian

RE: [GD-Windows] Messed up windows after fullscreen

[Daniel V. <vo...@ep...>]

You have to attach yourself to the thread that owns the foreground window to
be able to steal the 'foregroundness' from it using SetForegroundWindow.

- Daniel Vogel, Programmer, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Thursday, September 27, 2001 10:02 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] Messed up windows after fullscreen
>
>
> Hmmm, I wasn't using SetActiveWindow (I was using SetFocus -- could
> Windows possibly provide enough variations on these?!).  Also, what's
> the AttachThreadInput business all about?
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

Re: [GD-Windows] Messed up windows after fullscreen

[Aaron H. <Vid...@ho...>]

And there are yet even MORE variants of making windows on top and
visible.. :\

Have you done something like this?

  // alternate startup mode, to bring up full screen.
  hWnd = CreateWindow(ThisWindowClass,
                      appGetName(),
                      WS_POPUP,
                      0, 0,
                      oglWidth, oglHeight,
                      NULL, NULL,
                      hInstance,
                      NULL );

// THIS MAY BE IMPORTANT! Make the app window visible...
  ShowWindow( hWnd, SW_SHOW );
  UpdateWindow( hWnd );


And, just to be sure, have you also handled the create message like
this?
  case WM_CREATE:
    // Remember our mSloth drawing context.
    hDC = GetDC( hWnd );

      if( oglFullscreen )
      {
        ChangeDisplayMode();
      }

        // Select our precious pixel format.
      SetDCPixelFormat( hDC );

      // Yeppers, make something that OpenGL understands.
      hRC = wglCreateContext( hDC );
      wglMakeCurrent( hDC, hRC );

    ReleaseDC( hWnd, hDC );
    break;

This seems to work well in my case.  I haven't had any problems with
apps (debugger on break points) stealling focus and screwing up the
other windows.

Percision is tricky...
- Aaron.

Brian Hook wrote:
> 
> Hmmm, I wasn't using SetActiveWindow (I was using SetFocus -- could
> Windows possibly provide enough variations on these?!).  Also, what's
> the AttachThreadInput business all about?
> 
> Brian
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] Messed up windows after fullscreen

[Brian H. <pu...@py...>]

So this is only really necessary if you're doing all this magic within
WM_CREATE, correct?  Assuming I do it after calling CreateWindow() and
thus from my app's primary thread, I should be okay, no?


Brian

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Daniel Vogel
> Sent: Thursday, September 27, 2001 7:18 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] Messed up windows after fullscreen
> 
> 
> You have to attach yourself to the thread that owns the 
> foreground window to be able to steal the 'foregroundness' 
> from it using SetForegroundWindow.
> 
> - Daniel Vogel, Programmer, Epic Games Inc.

RE: [GD-Windows] Messed up windows after fullscreen

[Brian H. <pu...@py...>]

> // THIS MAY BE IMPORTANT! Make the app window visible...
>   ShowWindow( hWnd, SW_SHOW );
>   UpdateWindow( hWnd );

Yep, I'm doing that.  Actually, I'm now doing:

CreateWindow();
ShowWindow();
UpdateWindow(); //this shouldn't be necessary if you don't handle
WM_PAINT
SetForegroundWindow();
SetActiveWindow();
SetFocus();

Thorough enough? =)

>   case WM_CREATE:
>     // Remember our mSloth drawing context.
>     hDC = GetDC( hWnd );
> 
>       if( oglFullscreen )
>       {
>         ChangeDisplayMode();
>       }
> 
>         // Select our precious pixel format.
>       SetDCPixelFormat( hDC );
> 
>       // Yeppers, make something that OpenGL understands.
>       hRC = wglCreateContext( hDC );
>       wglMakeCurrent( hDC, hRC );
> 
>     ReleaseDC( hWnd, hDC );
>     break;

I'm doing that after CreateWindow() and not in WM_CREATE.  Is there a
particular reason that you do it in WM_CREATE?  AFAIK (but this is an
assumption), CreateWindow() dispatches WM_CREATE synchronously.

Brian

Re: [GD-Windows] Messed up windows after fullscreen

[Aaron H. <Vid...@ho...>]

Yep, setting a break point confirms that WM_CREATE is generated and
called within CreateWindow().  Wish I had a reasonable answer to why
OpenGL is initialized in WM_CREATE. However, that skeleton I sent seems
to always work fine.

Looking around, there seems to be a progression of messages delivered by
the OS when CreateWindow is called, and WM_CREATE is somewhere in the
middle.  Wish I could just walk through the OS code base and see what it
really does!

Good luck.
- Aaron.

Brian Hook wrote:
> Yep, I'm doing that.  Actually, I'm now doing:
> 
> CreateWindow();
> ShowWindow();
> UpdateWindow(); //this shouldn't be necessary if you don't handle
> WM_PAINT
> SetForegroundWindow();
> SetActiveWindow();
> SetFocus();

> I'm doing that after CreateWindow() and not in WM_CREATE.  Is there a
> particular reason that you do it in WM_CREATE?  AFAIK (but this is an
> assumption), CreateWindow() dispatches WM_CREATE synchronously.

RE: [GD-Windows] Messed up windows after fullscreen

[Philip T. <pt...@mi...>]

WM_CREATE is a post-notification of window creation. at that point, you =
should be able to use the window handle with other Win32 API calls.

I suspect that is why OGL is initialized during WM_CREATE.

note if for some reason you want to fail the creation of your own =
window, you need to handle WM_NCCREATE, which is the pre-notification of =
window creation. by returning either FALSE or -1 ( cant remember off the =
top of my head, its been a while since I wrote custom controls where =
this can be important ) then you will get an invalid window handle back =
from CreateWindow.

any good introductory Win32 tome should discuss, somewhat, the =
initialization sequence of messages duing window creation. serious =
spelunkers should be familiar with Matt Pietreks' work.

> -----Original Message-----
> From: Aaron Hilton [mailto:Vid...@ho...]
> Sent: Friday, September 28, 2001 6:42 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] Messed up windows after fullscreen
>=20
>=20
> Yep, setting a break point confirms that WM_CREATE is generated and
> called within CreateWindow().  Wish I had a reasonable answer to why
> OpenGL is initialized in WM_CREATE. However, that skeleton I=20
> sent seems
> to always work fine.
>=20
> Looking around, there seems to be a progression of messages=20
> delivered by
> the OS when CreateWindow is called, and WM_CREATE is somewhere in the
> middle.  Wish I could just walk through the OS code base and=20
> see what it
> really does!
>=20
> Good luck.
> - Aaron.
>=20
> Brian Hook wrote:
> > Yep, I'm doing that.  Actually, I'm now doing:
> >=20
> > CreateWindow();
> > ShowWindow();
> > UpdateWindow(); //this shouldn't be necessary if you don't handle
> > WM_PAINT
> > SetForegroundWindow();
> > SetActiveWindow();
> > SetFocus();
>=20
> > I'm doing that after CreateWindow() and not in WM_CREATE. =20
> Is there a
> > particular reason that you do it in WM_CREATE?  AFAIK (but=20
> this is an
> > assumption), CreateWindow() dispatches WM_CREATE synchronously.
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20

Re: [GD-Windows] Messed up windows after fullscreen

[Corrinne Y. <cor...@sp...>]

----- Original Message -----
From: "Philip Taylor" <pt...@mi...>
To: <gam...@li...>
Sent: Tuesday, October 02, 2001 3:39 PM
Subject: RE: [GD-Windows] Messed up windows after fullscreen


any good introductory Win32 tome should discuss, somewhat, the
initialization sequence of messages duing window creation. serious
spelunkers should be familiar with Matt Pietreks' work.

-- The bad thing is that by the time the next Matt P. book is on the shelf,
new windows messages, and message proc behaviors, for newer versions of
windows, already make some of it obsolete.

-- It eventually comes down to trial and error shared among programmers,
word of mouth with Microsoft engineers, and sometimes Microsoft seminars, on
a continual cycle.

-- This applies more to the whole "activate" "losing context" situation than
for "creation."

-- Perhaps an online up to the minute column (maintained by someone at MS,
perhaps Phil?) of "now" what is the correct way to handle deactivate, and
what kind of things would be lose, and how to handle them, (and the creation
loop again, and the shutdown process again) for each relevant version of
Windows OS version.

-- May be more contemporary.

Corrinne

P.S. It is not too bad, usually it is no more than a few lines of code to
add or change everytime new OS changes. The "bad" would be for already
released applications that doesn't get patched.

[GD-Windows] Windows Standards Guide?

[Aaron H. <Vid...@ho...>]

What I would like to see is a consice "Windows Standards Guide" where
'proper' programming behaviour is defined and expected by MS.

Anyone here know of such a thing?

Corrinne Yu wrote:
> 
> any good introductory Win32 tome should discuss, somewhat, the
> initialization sequence of messages duing window creation. serious
> spelunkers should be familiar with Matt Pietreks' work.

[GD-Windows] Win2K SP2 debugging slowdown?

[Javier A. <ja...@py...>]

Hi all,

We have been tracking a weird situation we have, where on some of our dev.
machines our game takes several seconds to shut down. We eventually found
out the following:

- The game must be running in a debugging session under MSVC (haven't tried
other debuggers).
- The computer must have Windows 2000 _with_ service pack 2 installed.

The slowdown happens during a loop that deletes several thousand dynamic
memory blocks. Most of the time, sometimes it doesn't. Similar symptoms also
appear in other places, like our streaming music decoding thread.

Running MSDEV under VTune we found that, when the slowdown happens, most of
the time during that loop is spent inside the operating system, spread
half-and-half in two functions: RtlCompareMemoryUlong() and
RtlFillMemoryUlong().

Has anyone heard of something like this?

Javier Arevalo
Pyro Studios

RE: [GD-Windows] Messed up windows after fullscreen

[Philip T. <pt...@mi...>]

> -- Perhaps an online up to the minute column (maintained by=20
> someone at MS,perhaps Phil?) of "now" what is the correct way to =
handle=20
> deactivate, and what kind of things would be lose, and how to handle =
them,=20
> (and the creation loop again, and the shutdown process again) for each =
relevant=20
> version of Windows OS version.

sorry, but I am way too busy with DX issues to volunteer for this one.

> -----Original Message-----
> From: Corrinne Yu [mailto:cor...@sp...]
> Sent: Tuesday, October 02, 2001 2:21 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] Messed up windows after fullscreen
>=20
>=20
> ----- Original Message -----
> From: "Philip Taylor" <pt...@mi...>
> To: <gam...@li...>
> Sent: Tuesday, October 02, 2001 3:39 PM
> Subject: RE: [GD-Windows] Messed up windows after fullscreen
>=20
>=20
> any good introductory Win32 tome should discuss, somewhat, the
> initialization sequence of messages duing window creation. serious
> spelunkers should be familiar with Matt Pietreks' work.
>=20
> -- The bad thing is that by the time the next Matt P. book is=20
> on the shelf,
> new windows messages, and message proc behaviors, for newer=20
> versions of
> windows, already make some of it obsolete.
>=20
> -- It eventually comes down to trial and error shared among=20
> programmers,
> word of mouth with Microsoft engineers, and sometimes=20
> Microsoft seminars, on
> a continual cycle.
>=20
> -- This applies more to the whole "activate" "losing context"=20
> situation than
> for "creation."
>=20
> -- Perhaps an online up to the minute column (maintained by=20
> someone at MS,
> perhaps Phil?) of "now" what is the correct way to handle=20
> deactivate, and
> what kind of things would be lose, and how to handle them,=20
> (and the creation
> loop again, and the shutdown process again) for each relevant=20
> version of
> Windows OS version.
>=20
> -- May be more contemporary.
>=20
> Corrinne
>=20
> P.S. It is not too bad, usually it is no more than a few=20
> lines of code to
> add or change everytime new OS changes. The "bad" would be for already
> released applications that doesn't get patched.
>=20
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20