Screen resolutions available for non-full screen don't really make sense.

[Al Riddoch]

Ember 0.5.5 shows a new behavior which I suspect is a side effect of running with OGRE 1.6.

When selecting the screen resolution from the initial OGRE dialog, if full screen is set to "Yes" the only resolutions available are useless on a dual monitor configuration.

As a specific example, I have a dual monitor Xinerama config which is overall size 3840x1200. The smallest res available is 2560x1024 which is ridiculously big, and has a very wide aspect ratio which renders very poorly. Most full screen OpenGL applications are able to interact with GLX and Xinerama well enough to offer single monitor full screen resolutions on this configuration. I accept that this may be an upstream bug, but it is a major issue.

A second related issue is that if I set full screen to "No" the same limited set of screen resolutions given above are the only available. Previous versions offered the fairly standard sensible defaults, like 800x600, 1024x768 and 1280x1024. I don't think there is any reason why the windowed resolutions should be restricted to the same set as the full screen ones, and on my configuration I suffer the performance penalty of all resolutions being spread across monitors and being way too large to render fast. I have no yet found a usable combination on this system, though Ember 0.5.4 ran fine at 800x600.

[Erik Ogenvik (erik-ogenvik)]

What make is your GPU?

I've looked through the posts over at the Ogre3d forum and this seems to be an issue that more people are reporting now that Ogre 1.6 is being used more. The background is the change that happened to the GLX backend for the 1.6 series. It's apparently now more dependent on the resolutions reported by X (or perhaps even xrandr), which in some cases seems too restrictive.
For example: http://www.ogre3d.org/phpBB2/viewtopic.php?t=43063 and http://www.ogre3d.org/phpBB2/viewtopic.php?t=39933

I myself uses the nvidia twinview configuration with two separate screens without problems, but that setup is quite different from using Xinerama with one common desktop area split into two screens. Without a proper setup it's a bit hard to debug; I can take a look at how I would set up Xinerama.

[Erik Ogenvik (erik-ogenvik)]

Some more posts about this subject:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=44458&start=0&postdays=0&postorder=asc&highlight=
http://www.ogre3d.org/phpBB2/viewtopic.php?t=46489&start=0&postdays=0&postorder=asc&highlight=

[Al Riddoch (alriddoch)]

I am using NVIDIA. The problem is pretty much exactly as you describe. The resolutions available are only those available to xrandr.

I am using TwinView which I am aware does not use Xorg's Xinerama infrastructure for multiple screens. It does however allow the Xinerama X extension to be used to allow the window manager and other applications to be aware of the existence of the two screens that divide the common framebuffer. While it has been some time since I wrote or dealt with code at that level, if I recall correctly it should be possible for the low level code than handles setting screen resolutions to use Xinerama alongside GLX to discover the number and positions of the monitors.

[Erik Ogenvik (erik-ogenvik)]

Could you try adding
Option "DynamicTwinView" "Off"
to x.conf as described here: http://www.ogre3d.org/phpBB2/viewtopic.php?p=284785#284785 ?

[Alexey Torkhov (atorkhov)]

Wasn't this was fixed with 1.5.6?

[Al Riddoch (alriddoch)]

Ogre 1.5.6?

No, it actually only became a problem with OGRE 1.6 when a new GLX layer came in which got it's available resolutions from GLX IIRC.

I worked around it by manually specifying a resolution in ember's user config file.

Al

[Erik Ogenvik (erik-ogenvik)]

You mean Ember 0.5.6? Our hope was that Ogre 1.6.2 should have fixed this, but it didn't. As Al said, the issue is that Ogre gets its screen resolutions from GLX, which apparently not always is telling the truth.
Now, we're currently using the Ogre built in configuration dialog since it's convenient. But we could also provide our own. Perhaps that's something we could look into (and then provide our own list of resolutions). But that would mean we would need to devote resources to that, and it might be that this issue could be solved in Ogre instead.

[Erik Ogenvik (erik-ogenvik)]

Can you check if this issue is still present when running the latest Ember from master? It now uses Ogre 1.7 which perhaps have rectified this behavior.

[Al Riddoch (alriddoch)]

Yeah, still a problem.