7 replies to this topic

[netwalker]

Hello All,

I'm having a problem ( actually its been in my engine for over 9 months now and I want to lance it ). I'm trying to do a mode toggle from fullscreen to windowed and vice versa in OpenGL on Windows. Yes I know that the NeHe tutorials do a mode toggle but that destroys the entire application. I don't want to do that, if I can help it. Anyway the algorithm that I've implemented works when both the desktop and fullscreen colour bit depth is the same, however when the colour depths are different (desktop 16 bits, fullscreen 32 bits) I get the following error message:

Failed to set the pixelformat for the current device cColorBits: 32, cDepthBits: 24, cStencilBits: 0, Errorcode: 0x000007d0

the errorcode value is the value being returned from GetLastError() which I believe means "pixelformat is invalid". The algorithm that I'm using to do the mode toggle is as follows:

delete pixelformat (deletes rendering and device contexts)
toggle window state
set new displaymode
setup new pixelformat (create new device and render contexts)

any helps much appreciated,

netwalker.

[Wernaeh]

From the MSDN, in regards to SetPixelFormat:

Quote

If hdc references a window, calling the SetPixelFormat function also changes the pixel format of the window. Setting the pixel format of a window more than once can lead to significant complications for the Window Manager and for multithread applications, so it is not allowed. An application can only set the pixel format of a window one time. Once a window's pixel format is set, it cannot be changed.

So, the correct way to do this would be to destroy the entire window, and recreate it again.

By the way, why do you want to support different target window pixel formats ?

Also note, that for normal display mode changes (i.e. windowed to fullscreen) or resolution changes, you won't need to touch the pixel format of your window...

Cheers,
- Wern

[netwalker]

Wernaeh said:

From the MSDN

I guess I wasn't looking hard enough then ;). Its no problem. I already have code to destroy and rebuild resources as necessary. I just thought maybe there "might" have been away of doing it since D3D can and even DirectDraw can do mode toggles without the need to destroy the window, but I suppose they manage pixelformats differently.

Wernaeh said:

By the way, why do you want to support different target window pixel formats ?

No specific reason. Some people use 16bit colour depth for their desktop, others use 32 bit. So I just thought "support both". Unless of course I can make a "safe assumption" that everybody is now using 32bit desktops, but I think that may comeback to bite me on the a**.

Wernaeh said:

for normal display mode changes (i.e. windowed to fullscreen) or resolution changes, you won't need to touch the pixel format of your window...

Does that include changes to colour depth too?.

thanks.

[Wernaeh]

Quote

Does that include changes to colour depth too?.

No, I don't think so - just consider that maybe a 16bit colour depth is only supported with a 16-bit depth buffer, so they can have interleaved colour / depth in a 32-bit-per-pixel format. Now if you change colour resolution from 32-bit to 16-bit, your old format may not be supported anymore.

I can even remember that some old hardware (GeForce 1 era) trashed all video memory resources on normal display changes as well, so you still had to reload textures and similar - the clean way always is to recreate the window, as far as I know (Anybody out there can make a definitive statement on that?)

Cheers,
- Wernaeh

[Kenneth Gorking]

netwalker said:

Does that include changes to colour depth too?.

It does, as far as I remember.

Edit: Too slow, and probably wrong :)

[Reedbeta]

netwalker said:

Unless of course I can make a "safe assumption" that everybody is now using 32bit desktops

Honestly, that sounds like a pretty safe assumption to me.

[Wernaeh]

Quote

Honestly, that sounds like a pretty safe assumption to me.

That's the way I'd suggest for almost all projects, as well - especially smaller, private ones.

Just settle with maybe one or two pixel formats your app supports - and tell the user to upgrade his hardware if these aren't available. These days, almost all hardware will support 32-bit Colours 24-bit Depth 8-bit Stencil - so why go for anything else ?

Cheers,
- Wernaeh

[netwalker]

It makes things really simple by using one pixelformat. If of course my users start moaning about not supporting 16 bit color depths I can always redirect them here... hehehe.

Thanks a lot for input guys.

netwalker.