gamedevlists-windows — List for discussing game development on the Windows platform

Re: [GD-Windows] Win2K SP2 debugging slowdown?

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

If only it were that easy. :)

The situation happens when the game is run under the debugger, using the
debug runtime or not doesn't make a difference. The slowdown magnitude is
huge, about is a few seconds (5-7) versus a couple tenths of a second so I
have ruled out cache, fragmentation and similar issues.

Besides, why does it happen only after installing the Win2K Service Pack 2?
I guess it has something to do with additional security features of the SP2
for processes that run under a debugger, but that's just my own elaboration,
and still leaves me with no idea what triggers the slowdown and how to fix
it.

The hardware configuration doesn't matter, since it's happened everywhere
from 2-year-old P3-450's to brand-new 1.4GHz AMDs, 256 or 512Mb RAM. Heh all
machines have NVidia cards but I really doubt that has anything to do, since
the slowdown happens in areas with zero D3D interaction - sound and massive
memory deallocations so far.

Javier Arevalo
Pyro Studios

----- Original Message -----
From: "Tom Forsyth" <to...@mu...>
To: "GDWindows" <gam...@li...>
Sent: Wednesday, October 03, 2001 1:47 PM
Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?


> Sounds like the debug runtime is checking every freed block to make sure
you
> haven't scribbled off the ends. When you allocate stuff, it pads the start
> and end with some special characters. IIRC, it pads 16 bytes off start and
> end with FD. When you call free() or delete() or whatever, it checks that
> the FDs are still there.
>
> I have no idea hy it does this more or less than normal though - maybe
> because your memory is heavily fragmented on those runs, so cleanup is
quite
> messy?
>
> Tom Forsyth - Muckyfoot bloke.
>
> What's he up to now (and can I have a go)?
> http://www.eidosinteractive.com/downloads/search.html?gmid=86
>
> > -----Original Message-----
> > From: Javier Arevalo [mailto:ja...@py...]
> > Sent: 03 October 2001 08:28
> > To: GDWindows
> > Subject: [GD-Windows] Win2K SP2 debugging slowdown?
> >
> >
> > 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().

RE: [GD-Windows] Win2K SP2 debugging slowdown?

[Tom F. <to...@mu...>]

Sounds like the debug runtime is checking every freed block to make sure you
haven't scribbled off the ends. When you allocate stuff, it pads the start
and end with some special characters. IIRC, it pads 16 bytes off start and
end with FD. When you call free() or delete() or whatever, it checks that
the FDs are still there.

I have no idea hy it does this more or less than normal though - maybe
because your memory is heavily fragmented on those runs, so cleanup is quite
messy?

Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]
> Sent: 03 October 2001 08:28
> To: GDWindows
> Subject: [GD-Windows] Win2K SP2 debugging slowdown?
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

[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] Windows Standards Guide?

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

MSDN, the Win32 doc-set, and the headers are primary source for Windows =
Developers.

then there are the "respected" volumes on Win32 programming.=20

MSDN and the relevant books do a pretty good job wrt to standard Win32 =
programming issues. thats were you will find 'proper' Win32 programming =
info.

it is very hard to serve all needs, of course, in these resources; but =
its rare that you need to worry about things like WM_CREATE vs =
WM_NCCREATE. so in the vast majority of cases these resources do a very =
respectable job. I mentioned it because the discussion included a query =
as to why someone would choose WM_CREATE.

PS. think about doing Windows programming pre-MSDN...thats when it was =
truly a challenge to get good info.

> -----Original Message-----
> From: Aaron Hilton [mailto:Vid...@ho...]
> Sent: Tuesday, October 02, 2001 3:18 PM
> To: Corrinne Yu
> Cc: gam...@li...
> Subject: [GD-Windows] Windows Standards Guide?
>=20
>=20
> What I would like to see is a consice "Windows Standards Guide" where
> 'proper' programming behaviour is defined and expected by MS.
>=20
> Anyone here know of such a thing?
>=20
> Corrinne Yu wrote:
> >=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
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20

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

[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.

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.

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

[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

[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...>]

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] Re: Gamedevlists-windows digest, Vol 1 #7 - 9 ms gs

[Tom F. <to...@mu...>]

No, I don't know why it happens either.

The usual trick is to move the cursor to the bottom-right of the screen as
well as hiding it.

Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Josiah Manson [mailto:jos...@ho...]
> Sent: 28 September 2001 18:17
> To: gam...@li...
> Subject: [GD-Windows] Re: Gamedevlists-windows digest, Vol 1 
> #7 - 9 msgs
> 
> 
> I have had a problem several times in the past with my opengl 
> programs, in 
> that when it goes to full screen, the mouse will not become hidden 
> immediately. Sometimes it does as it is supposed to, but 
> other times it is 
> necessary to move the mouse around to get the cursor to disappear.
> 
> I am not able to program for a while, but I believe that I 
> was calling the 
> windows function ShowCursor(FALSE); Has anyone else had this 
> problm? Any 
> solutions? Does the problem exist for DX also?
> 
> 	-Josiah Manson
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

[GD-Windows] Re: Gamedevlists-windows digest, Vol 1 #7 - 9 msgs

[Josiah M. <jos...@ho...>]

I have had a problem several times in the past with my opengl programs, in 
that when it goes to full screen, the mouse will not become hidden 
immediately. Sometimes it does as it is supposed to, but other times it is 
necessary to move the mouse around to get the cursor to disappear.

I am not able to program for a while, but I believe that I was calling the 
windows function ShowCursor(FALSE); Has anyone else had this problm? Any 
solutions? Does the problem exist for DX also?

	-Josiah Manson

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

RE: [GD-Windows] loading a truetype font

[Marcin W. <Ma...@zo...>]

try AddFontResource().  Might work for ya. 

Marcin

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Gabor Farkas
Sent: Friday, September 28, 2001 1:31 AM
To: gamedev-windows
Subject: [GD-Windows] loading a truetype font


hi,

is there a way to load a truetype font (*.ttf) from the disk and use it?
without installing it, of course...

gabor
--------------------------------
Just because a thing can be done does not mean it must be done or should be
done.



_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

[GD-Windows] loading a truetype font

[Gabor F. <xl...@po...>]

hi,

is there a way to load a truetype font (*.ttf) from the disk and use it?
without installing it, of course...

gabor
--------------------------------
Just because a thing can be done does not mean it must be done or should be
done.

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

[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...>]

> 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...>]

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

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

I believe you have to restore the display settings before closing
everything down. I've attached a Win32 skeleton application that was
developed for the OpenGL Challenge.

An example:
void RestoreDisplayMode()
{
  ChangeDisplaySettings(0, 0);
}

LRESULT CALLBACK SkeletonProc( HWND hWnd, UINT uMsg, WPARAM wParam,
LPARAM lParam )
{
	// Keep drawing stuff around.
	static HGLRC hRC;
	static HDC hDC;

//-- snip --
  case WM_DESTROY:
		wglMakeCurrent( hDC, NULL );
		wglDeleteContext( hRC );

		if( fullscreen )
		{
		  RestoreDisplayMode();
		}

		PostQuitMessage( 0 );
		break;
//-- /snip --

Hope this helps...
- Aaron.

Brian Hook wrote:
> 
> I'm sure this kind of thing comes up all the time, but I'm getting
> really annoyed that when I go fullscreen and return that all my windows
> (not icons though) are scrunched down.  Is this a driver issue?  This is
> on Win2K SP2 w/ GF3 12.41 using ChangeDisplaySettings().
> 
> 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...>]

> 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

[Evil K. <evi...@ho...>]

Hi Brian

    ok, I've noticed this problem too, especially when I switch between the
two, not necessarily when I start in fullscreen then exit back to windows,
but in your win32 code when you close the window, or exit the app, do you
call

ChangeDisplaySettings(NULL,0)

because I've read and I'm quite sure this will "reset" your default windows
screen, so when you exit your app running at 640 back to your desktop
running at 1024 or higher, you should go back to 1024, instead of exiting to
windows, but keeping 640 as your res

thats if I read your question right, otherwise :P oops

kosh

----- Original Message -----
From: "Brian Hook" <pu...@py...>
To: <gam...@li...>
Sent: Thursday, September 27, 2001 11:32 PM
Subject: [GD-Windows] Messed up windows after fullscreen


> I'm sure this kind of thing comes up all the time, but I'm getting
> really annoyed that when I go fullscreen and return that all my windows
> (not icons though) are scrunched down.  Is this a driver issue?  This is
> on Win2K SP2 w/ GF3 12.41 using ChangeDisplaySettings().
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

[GD-Windows] Messed up windows after fullscreen

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

I'm sure this kind of thing comes up all the time, but I'm getting
really annoyed that when I go fullscreen and return that all my windows
(not icons though) are scrunched down.  Is this a driver issue?  This is
on Win2K SP2 w/ GF3 12.41 using ChangeDisplaySettings().

Brian

Re: [GD-Windows] List Stuff

[Evil K. <evi...@ho...>]

Hi tom

> I don't care about bandwidth. I care about this list and the others
> providing a good service to the people that subscribe to them.

I do care about bandwidth, plus I was more interested in hearing people talk
about why we are hear and not discussing stuff people here should already
know.  Hence my "wake up email"....

> >  get a grip, shut the fuck up, we dont
> >NEED people to sit around and moderate the list,
>
> If you keep posting crap like this comment you'll find yourself moderated
> (not the whole list .. just you). This is your only warning. Find other
> ways of expressing yourself.

Well I'd like to say if you're planning on threatening someone, do a good
job of it, because your threat it pretty worthless, so what if I get thrown
off this list? Do you think I'm going to cry? I doubt it.  Think before you
act, throwing worthless threats at people who have a greivance isnt going to
get you anywhere, not that I care what you think and I should think and hope
you dont care what I think either.

> >  just take a simple, if it's
> >offtopic, dont respond attitude, that email will get a few replies from
> >people who dont take notice of this, but in general, a simple, this email
is
> >offtopic, take it to <insert list name> should do it
>
> Actually, if you look back to my original post and the original thread,
> you'll see that's exactly what happened.

Thats great and then more emails came with the same message.

> >STOP TALKING ABOUT IT!!! it's causing a bigger problem than his original
off
> >topic post
>
> You realize that the post you just replied to was calling for the thread
to
> be closed by the person who started it? That there was absolutely no need
> for you to reply except maybe for you to hear yourself talk and to insult
> others?

No, my need to reply was to bring an end to the pointless discussion of the
rules of mailing lists, people here came from other mailing lists, so they
know the rules from being there first, if this was a list full of people who
were computer illiterate perhaps it would be tolerable for discussion like
this, but I think it wasnt and I made myself pretty dammed clear I think

> You have crossed the line and made an ass out of yourself. I expect you to
> apologize to the list for what you've done.

Dont hold your breath, and no, I didnt make an ass of myself, you see, to do
that, I would have to give a shit what anyone here actually thinks about me,
because if I dont(and fyi, I dont), you're opinion doesnt count, so this
comment has relatively little value.....

> Don't reply to me to defend your actions. Continue to insult me on or off
> the list (imagine someone telling the list admin to shut the fuck up ...
> what the heck are you thinking???) and you'll find yourself moderated on
> _all_ the lists I run.

As if I would waste my valuable time talking to you or emailing you in
person, I dont give a fuck about you, from what I've read so far, you're a
fucking wanker.  But if you need telling, you can count on me to tell you,
and for your
information, I wasnt talking to you in specifics, I was talking in general.

So, if you want to take me from the list, do so, hell, in fact, I couldnt
care less whether you did or not, dont expect me to apologise to you, who do
you think you are anyway, your just some dickhead with an list
server, whoopy doo, plenty of people like you around, running lists just
like
this one (and most probably better). So go fuck yourself tom, I mean, think
about it this way, if you
dont, who will?

kosh