Is there any “good” way to get access to fullscreen in m$-windows (compatible for opengl drawing)? Or at least better than using ChangeDisplaySettings() and then drawing an window in front of all others? And then do I get hardware acceleration even in apps where the drawing area has been created that way?
What’s wrong with ChangeDisplaySettings and making a topmost, popup window the same size as the display? So far as hardware accelleration, just query the vendor/renderer with glGetString to see if you got a hardware accelerated driver or the default Microsoft driver. (Although, just because you don’t get the Microsoft driver, not everything is implemented in hardware on most cards.)
I’ve always wondered about this…in Direct3D, you can choose to go exclusive fullscreen, so that the 3d card can use real double buffering (having two surfaces in memory, so that a swap buffer command only changes which surface gets sent to the monitor), whereas in OpenGL, because we don’t have this option, it must always treat the front frame buffer as a window (block of memory which constantly gets copied onto the desktop).
Is this true? Or does the opengl driver (I’m thinking NVidia here) detect that the window is as big as the desktop, and so automatically chooses the faster frame swap method?
I doubt it would make such an assumption.
I dont know how ethical it would be but you can always get the device context of the monitor… I did this once on accident when messing around with multi-monitor stuff. Its kinda funny when you have a window border on one screen and OpenGL just rendering directly to the other screen. I dont recall exactly how I did it but it had something to do with enumerating display devices (lookup EnumMonitors or something of the like).
I wouldn’t worry overmuch about the performance hit of the full-screen window approach these days. A number of trends or possible trends (FSAA being the main one) mean that Amiga-style page flipping isn’t possible anyway.
There was a Carmack post on /. a while back which has some relevant points:
All signs are pointing towards a future without page flipping, so adding the
messy infrastructure for it now would be a mistake. Don’t let benchmarking
furor encourage a messy code architecture.
Points:
The benefit of page flipping is decreasing as more and more computation is
done per pixel to the back buffer.
In the old days of 2D scrollers, you might barely cover the screen with one
pass of writes, so page flipping could double your speed over blitting.
On a typical modern 3D game that becomes fill limited, under 25% of the
performance is in the blit, and often under 10% in scenes with significant
overdraw.
In upcoming games that composite 20+ layers of textures, the cost of a blit
is down in the noise.
Blits add flexibility. Anti-aliasing is better done through a blit operation
than with a deep front buffer. Other operations, like converting from a 64 bit
work pixel to a 32 bit display pixel, or performing convolutions, are also
better done with blits. Back buffers are more optimally arranged in tiled
patterns, while front buffers prefer linear scans. Basically, our back buffers are starting to look less like raster Page flipping doesn’t apply to windowed
rendering unless you butcher the X server to render all 2D to multiple buffers
and clip all 3D operations. I consider that a bad thing. Making the full
screen rendering more distant from windowed rendering is also a bad thing. Every
implementation of page flipping brings in a class of bugs, and obfuscates
several code paths. It’s not worth it.
Well, GOD has spoken… 
Yeah… you know, it would do wonders for morale if he could be wrong just once…
Not holding my breath, though.
I think Carmack is underestimating just how important 10% can be.
- Matt
Originally posted by BwB:
I dont know how ethical it would be but you can always get the device context of the monitor… .
Well you can use GetDC( NULL ) or CreateDC( … ) to get the Desktop DC (CreateDC also takes a DEVMODE struct, so you can theoreticly get the DC for a printer/other monitor aswell).
I tested GetDC( NULL ) once, but if i remember it right it didnt look very nice… Like every second frame my desktop showed up (maybe windows redrawing the desktop while i was messing around with it )
Drawing a window in front of everything else maybe isnt that bad at all…
BTW: How do i check where my (back-) buffers are resident (RAM, Videomemory-stuff or whatever)?
[This message has been edited by CViper (edited 03-17-2001).]
I don’t think getting the DC of the desktop will help to provoke OpenGL into page-flipping. McCraighead…is there any way of doing page flipping in OpenGL?
I’ve just been sniffing around…do we use WGL_SWAP_METHOD, WGL_SWAP_EXCHANGE_ARB ?