Resizing the Window on the fly

[Baker]

I want to bury this here (it's on my "someday try this list"). On OS X with the Fruitz of Dojo port, you can resize the Quake window with the mouse.

And thinking of that, it shouldn't be that difficult in Windows (I can think of one potential hurdle).

Barring that potential hurdle (does the OpenGL window need reinitialized ... ugh if yes), it would just be a matter of updating the 2D width and "glwidth/glheight" of the window within the engine.

Plus setting the window creation to allow resizing, reading the messages and setting a hook to limit the minimum window resizing to something like 320x200 (HUD can't go smaller than 320 width, menu can't go less than 200 height).

Rook has a preoccupation with dual monitors, personally I'd like to see dual monitor Quake, but I find it annoying that even within a single monitor you can't resize the window in windowed mode. Or just click maximize.

/Personally, I don't plan on playing with this soon. But I want to make sure I don't forget and sounds like an interesting topic.

[frag.machine]

From the OpenGL side I don't see problems, just be sure to call glViewPort() to adjust the screen dimensions after resizing and you're done AFAIK.

[Spike]

The only issues are driver bugs.
FTE supports it. ATI drivers suck. Or at least they used to.
Generally the glitches don't appear until the next map change or so.
With stuff like VBO the glitches are more likely to actually be fixed properly in recent drivers.

[mh]

A good general rule with ATI is "if it doesn't work in Direct3D it won't work in OpenGL". On-the-fly resizing is possible in Direct3D, but it would require a device reset as the backbuffer size is an intrinsic property of the device, is set at creation time, and can only be changed via a reset (which would also cause a complete loss of state as well as of certain resources). I'd guess the same applies to ATI OpenGL drivers, but it's anybody's guess where ATI have squirreled the code away in the API. Other OpenGL implementations probably handle this automatically, most likely that it still happens but it's not shoved in your face.

[Spike]

I've had dynamic resizing with d3d too, but like you say, the backbuffer itself doesn't change size. It just rescales it.
I've seen d3d apps resize windows without pixel doubling effects, just not fully realtime. I don't know enough about d3d to know what its doing. But then again, as d3d could flush out your entire texture state on a whim anyway, reloading textures is not generally an issue.

You'll probably still get a slight stall with opengl too.
But yeah, work out the new client width/height (GetClientRect), make sure your glViewPort is updated, and the rest is the fault of your GL drivers. Even if you change screen resolution between. Changing pixel depth and still expecting decent performance is a little rude though.

The current ATI drivers are fine with window resizing, at least on this computer.

[Baker]

FTE supports it.

It's true!

-1 Baker's list of stuff