[OGRE-154] When a monitor is in portrait mode FSAA could not be set from ogre.cfg file on restoreConfig()

[paroj]

[reporter="bjoe", created="Tue, 26 Feb 2013 14:52:46 +0100"]

When a monitor is set to portrait mode (in Windows 7), the FSAA can accept only one value - '0' (NO Anti Alias).
Changing to a video mode with the right resolution, brings back the FSAA options (0, 2, 4, 8, 8 Quality)

The current implementation of restoreConfig() reads the ogre.cfg data to a MultiMap and then iterates through and sets the render system parameters. The problem is that it sets the 'FSAA' parameter BEFORE the 'Video Mode' parameter and causing the FSAA value to be ignored.

The obvious solution is to change the order of which the parameters are set so that the 'Video Mode' is set before the 'FSAA'.

[paroj]

[author="spacegaier", created="Sat, 28 Sep 2013 15:29:01 +0200"]

What render system is causing that issue?

[paroj]

[author="bjoe", created="Sat, 28 Sep 2013 15:36:40 +0200"]

I worked with D3D9.

[paroj]

[author="spacegaier", created="Sat, 28 Sep 2013 19:22:13 +0200"]

From my initial investigation, I think the issue is a bit different.

1. It is by design, that only once a valid video mode has been set, possible FSAA values can be proposed (since only once we know the video mode the D3D9 rendering system provides those values).

2. The problematic part is, that when in portrait mode the config dialog inits the video mode value with the default "800x600 32bit" which is invalid in that display orientation. That is something I will have to look into.

When you call the application for a second time in portrait mode, the correct video mode is set (if you selected one in the first run), but the old FSAA selection is not restored!

[paroj]

[author="bjoe", created="Sat, 28 Sep 2013 23:09:17 +0200"]

I think you are right, but this is another issue, there are two issues here:
1. Handling of the portrait mode (as you mentioned)
2. The parsing of the ogre.cfg file within the restoreConfig(), as I have described