Setting the video mode in X

[bernt]

I'm working on my little game library again... and now I'm trying to change the screen resolution to match that of the window I'm making.

I thought that glutEnterGameMode would change the resolution but this is not the case, so I came up with a little hack.

util.cpp:

#include <cstdlib>
#include <iostream>
#include <GL/glut.h>

static int original_w, original_h;
void reset_resolution(void)
{
	char mode[50];
	sprintf(mode,"xrandr --size %dx%d",original_w,original_h);
	system(mode);
}

void make_window(int w, int h, char *title, int fullscreen)
{
	if (fullscreen) {
		original_w = glutGet(GLUT_SCREEN_WIDTH);
		original_h = glutGet(GLUT_SCREEN_HEIGHT);

		char mode[50];
		sprintf(mode,"xrandr --size %dx%d",w,h);
		system(mode);
		atexit(reset_resolution);

		sprintf(mode,"%dx%d:32",w,h);
		glutGameModeString(mode);
		glutEnterGameMode();
	}
	else {
		glutInitWindowSize(w,h);
		glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE);
		glutCreateWindow(title);
	}
}

I know all about the danger of using calls to system(). So surely there must be a better way to go about changing the resolution. Actually a cross-platform method would be preferable but from what I've read X doesn't play nice with programs trying to change the mode.

[dwks]

Does this function do what you want? glutFullScreen

If not I'm sure there's some link here that describes what you want. Google

[MK27]

Actually a cross-platform method would be preferable

For hopefully obvious reasons this is a nonsensical impossibility. You might find a lib or something that works the same on all platforms, but underneath it will have to rely on platform specific means.

The method used by glutFullScreen uses X, but there are a number of possible protocols* with which to make a fullscreen request -- in fact it is the window manager which has the final say. Glut uses MOTIF_HINTS, many newer "lite" window managers used by DE's like GNOME do not comply to this. There is a newer protocol called EWMH which will get better results, but you need to use Xlib directly. Also, while metacity (the GNOME WM) claims partial compliance to EWMH, it is not friendly to fullscreen requests.

Anyway, it's my impression that you are trying to change the whole screen resolution anyway, not just fullscreen the window. You might want to consider instead getting the root window dimensions via Xlib and then setting the window size to it. I do that with glut and GL, if you want I can post some code. This will not get rid of the title bar, etc, but it's a start...I eventually gave up researching this stuff.

* a consequence of the heterogenous *nix world.

[bernt]

glutFullScreen resizes the window to the current resolution. It doesn't change the video mode.

In the X implementation of GLUT, full screen is implemented by sizing and positioning the window to cover the entire screen and posting the _MOTIF_WM_HINTS property on the window requesting absolutely no decorations. Non-Motif window managers may not respond to _MOTIF_WM_HINTS.

If there is a way to stretch the window but not the resolution (if that makes any sense - what I mean is that the window takes up the full screen but the pixels are stretched so that, for example, only a 800x600 view has to be drawn) that would work too. But I don't know of any way to do that - maybe OpenGL supports some sort of stretching of the client?

EDIT:

getting the root window dimensions via Xlib and then setting the window size to it

Sounds interesting - I'll have to look into the root window stuff. Does resizing it effectively change the resolution?

ANOTHER EDIT: Quick looksie says that resizing the root window is what xrandr does. I might as well go with the xlib calls.

[dwks]

As you're probably aware, it's really easy to do this in the SDL. You do know that the SDL can be used in conjunction with OpenGL, right? I prefer the SDL to glut myself. glut's not really maintained any more and getting it to do certain stuff (like, apparently, getting a fullscreen 640x480 window . . .) is much harder than it needs to be.

[MK27]

The thing is, depending on changing the actual resolution is going to be ridiculously non-portable. You may get it to work on your computer, but chances are it then won't work on mine. This is very dependant on the hardware and how X is configured. In short, if you are expecting to write this into the program and then distribute it to others, DON'T. You are wasting your time. It will not work. Eg, 800x600 is only available on 4:3 ratio monitors. 16:9 widescreen monitors won't go there, at least not without some really obvious distortion.

Why is the window resolution so important? You can resize the window and it won't make that much difference to the scene...the scene dimensions do not have to match the window dimensions you use in glutInitWindowSize(). I tend to use static dimensions for a scene because it makes more sense to me that way, and then set the window size to the screen size (you can get the window size with DisplayWidth/DisplayHeight from X11/Xlib.h -- this works everywhere). Two or three lines of code.

glut's not really maintained any more

freeglut, the linux variant, is still actively developed, take a look at their homepage. I believe there is a freeglut for win too. The original glut is basically defunct, yeah.

[bernt]

As you're probably aware, it's really easy to do this in the SDL.

Yes, I am very aware. This is more of a learning experience. And personally I really like glut because of the callbacks. I don't have to deal with the event loop. But yes, SDL is very nice. And Allegro is even nicer.

Eg, 800x600 is only available on 4:3 ratio monitors. 16:9 widescreen monitors won't go there, at least not without some really obvious distortion.

Well the idea was to have a menu of available resolutions and the user could pick one. I'm just so used to those early FPS games where picking the resolution was a big deal, and so I wanted something similar. But now that I think about it, fill rates are so fast these days it doesn't really matter. It was just me being agnostic about speed I guess.

But thanks anyway.