Resizing a Window on the Fly (Windows)

[Baker]

Not rocket science, but here goes ...

Code: Select all

      case WM_SIZE:
         // We received a size message, width is in loword of lParam, height is in hiword
         WindowRect.right = LOWORD(lParam); // Width
         WindowRect.bottom = HIWORD(lParam);
         WindowRect.top = WindowRect.left = 0;
         // Update viewport
         GL_BeginRendering (&engine.video.glwindow.left, &engine.video.glwindow.top, &engine.video.glwindow.width, &engine.video.glwindow.height);
         SCR_UpdateScreen ();
         break;

(Yes GLQuake uses glx, gly, glwidth, glheight not my engine.video.glwindow stuffs. I have renamed and classified the globals to tell me what they are actually doing. I'm going to figure out some scheme to get all the globals into, well, it will probably be the cvar system in a way ... something like CVAR_ROM but a little more segregrated out.).

You also need to add a WS_SIZEBOX into the Window characteristics, again not rocket science.

By throwing a SCR_UpdateScreen in there, you get an instant refresh to avoid resizing ghosting while the window is being resized. (In truth, you also need a refdef_recalc in there. And if you have automatic console sizing, that too.)

While I'm not sure that on-the-fly resizing has much of a benefit, one benefit for me is being able to correctly detangle the mess that is the Quake video code.

I discovered, for example, that most engine use the wrong screen width and height in windowed mode because they include the title bar space in the height for aspect ratio calculation and the border space (a few pixels) for both the height and width.

[mh]

I discovered, for example, that most engine use the wrong screen width and height in windowed mode because they include the title bar space in the height for aspect ratio calculation and the border space (a few pixels) for both the height and width.

Not if they use AdjustWindowRect and use the adjusted rect for the parameters to their CreateWindow call, they don't.

[Baker]

I discovered, for example, that most engine use the wrong screen width and height in windowed mode because they include the title bar space in the height for aspect ratio calculation and the border space (a few pixels) for both the height and width.

Not if they use AdjustWindowRect and use the adjusted rect for the parameters to their CreateWindow call, they don't.

I see.

I also want the sizing to maintain the aspect ratio and have a minimum size so I guess I'm gonna be headed into subclassing.

Which brings up the question of what aspect ratio in -window mode is the right one (probably a check to get the desktop width/height) and then deal with the maximize button issue separately.

[Baker]

Wow. As I rewrite this stuff, the serious option of specifying which monitor screen of a dual screen monitor might be emerging. Maybe even the ability to use both screens.

Although I'm trying to think of what using both screens would be good for. And whatever type of pitfalls lie with, say, detecting OpenGL extensions for the wrong video card.

[Spike]

wgl is meant to deal with different drivers for different gl contexts, so wrong extensions for the wrong card is all handled for you, assuming you have an active context at the time (context driver is chosen based on which monitor your window is currently shown on, or something like that).

If its a dual display device, you can simply create one window which is large enough to cover both screens (with most engines that allow custom widths, you can just specify a width like 1280*480 for fullscreen and it'll work). However, if its not a dual display device, you will tend to end up with a black screen on the second one (also with windowed mode).

Of course, if you're using two monitors (but not 3), you'll likely want to do something about the position of the crosshair.

now, if you want to create two+ separate contexts at the same time, you need to use wglGetProcAddress with the specific correct context active at the time, and this would mean you'd be able to properly take advantage of machines with multiple independant display adaptors (flight sims tend to do this). In this case, yes, you would have context-specific extension flags, just as you would have context-specific textures, display lists, VBOs, etc. While you could try to share textures/etc between an nvidia and an ati context, I'm not sure I'd trust the drivers...
(wgl vs glx difference: wgl has context-specific GetProcAddresses (unlike direct exports), glx function pointers work regardless of which context was active at the time (working like direct exports). This applies to gl3+ functions too).

[Baker]

Hadn't planned quite that far ahead. But excellent points. 2x texture upload, 2x wglGetProcAddress, etc.

[Baker]

Wee ... only DarkPlaces (and I bet DirectQ ... but I didn't look) gets frustum calculations right for width < height resolutions. Admittedly, I didn't check Fitz.

A billion little termites rear their ugly heads ...

Stop? Heheh. No. That's the fun. If the journey didn't suck, it wouldn't be worth doing.

Once I get this done, a sane texture manager in place, unravel video mode initialization a bit more and dekludge the menu (create descriptive drawing array, no more spaghetti) ... things will start to get interesting.

[mh]

Wee ... only DarkPlaces (and I bet DirectQ ... but I didn't look) gets frustum calculations right for width < height resolutions. Admittedly, I didn't check Fitz.

Hmmm, I seem to have broken that a while ago, but it did work once.

[mh]

For arbitrary window resizing this might be useful in your MainWndProc:

Code: Select all

case WM_GETMINMAXINFO:
   {
      RECT windowrect;
      RECT clientrect;
      MINMAXINFO *mmi = (MINMAXINFO *) lParam;

      GetWindowRect (hWnd, &windowrect);
      GetClientRect (hWnd, &clientrect);

      mmi->ptMinTrackSize.x = 320 + ((windowrect.right - windowrect.left) - (clientrect.right - clientrect.left));
      mmi->ptMinTrackSize.y = 200 + ((windowrect.bottom - windowrect.top) - (clientrect.bottom - clientrect.top));
   }

   return 0;

Adjust the 320 and 200 to taste.

[Baker]

For arbitrary window resizing this might be useful in your MainWndProc:

Code: Select all

case WM_GETMINMAXINFO:
   {
      RECT windowrect;
      RECT clientrect;
      MINMAXINFO *mmi = (MINMAXINFO *) lParam;

      GetWindowRect (hWnd, &windowrect);
      GetClientRect (hWnd, &clientrect);

      mmi->ptMinTrackSize.x = 320 + ((windowrect.right - windowrect.left) - (clientrect.right - clientrect.left));
      mmi->ptMinTrackSize.y = 200 + ((windowrect.bottom - windowrect.top) - (clientrect.bottom - clientrect.top));
   }

   return 0;

Adjust the 320 and 200 to taste.

Will be playing that then ... thanks!

[mh]

Heads up that the "Show Desktop" button on Windows 7 may crash this. It sends a WM_SIZE to all windows and resets the client rects to [0,0,0,0]. So you probably should add a check for that.

[leileilol]

what about in software, just stretching the currently set mode!?!

[Baker]

Heads up that the "Show Desktop" button on Windows 7 may crash this. It sends a WM_SIZE to all windows and resets the client rects to [0,0,0,0]. So you probably should add a check for that.

+1 to testing plan