Full screen resolutions

[JensAyton]

I’m preparing to modernize the way full-screen mode is handled in 64-bit Mac Oolite. To do this, I need to know whether there’s any real need to support switching the screen resolution (or rather, rendering at a lower resolution and scaling up).

Do you run Oolite in a full-screen resolution that’s smallest than the biggest one available? Are you using 64-bit Oolite? (Open Latest.log, and read the first line. It will either say “(x86-64 test release)” or “(x86-32 test release)”.)

If so, how big is the benefit of using a lower resolution?

[Commander McLane]

I'm using 64-bit Oolite, and I wouldn't run anything than the biggest full screen resolution (1440x900 in my case).

However, I'm not using full screen anyway, but only play windowed. And I adjust the window size to my liking simply by dragging the lower right corner.

[Eric Walch]

Same as McLane. I use the maximum monitor resolution in fullscreen mode with a (x86-64 test release) under Mac OS X Version 10.6.8

(Although the new code currently throws an exception on startup with me as reported here)

[maaarcooose]

I'm running full screen 1200x800 on my MBP 13.

There's a specific 64 bit version?
How would I obtain that then?

!m!

[Eric Walch]

There's a specific 64 bit version?
How would I obtain that then?

On the mac, Oolite supports 64 bit. There is no special version. For windows it is still a problem to compile in 64 bit because not all the libraries available there are 64 bit clean.

If so, how big is the benefit of using a lower resolution?

Running 1.76.1 at 640 x 480 gives me a 10 to 20 % FPS increase when looking at the planet. But playing in 40 or 60 FPS does not feel that different so the speed increase is not worth the blurry screen. And I think I would start by lowering the other options first if I needed more speed (Reduced Detail & Detailed Planets)

[JensAyton]

There's a specific 64 bit version?
How would I obtain that then?

Oolite is a “fat binary”; it contains both 32-bit and 64-bit versions in the same application. The 64-bit version will be used if you’re running it on a 64-bit Mac with Mac OS X 10.6 or later. As I said above, you can see which version is used in the log. Generally, you shouldn’t have to care, but there’s likely to be a correlation between running low resolutions and 32-bit systems.

[Eric Walch]

I now fixed the problem of getting the exceptions on startup since the change. I did not correctly update the project file were new files were added.
Now trunk runs, but I can't switch to full screen anymore on snow leopard. Neither by cmd-F nor by the menu. When I find time, I can look and test myself. But maybe you know immediately were to look.

[JensAyton]

I now fixed the problem of getting the exceptions on startup since the change. I did not correctly update the project file were new files were added.
Now trunk runs, but I can't switch to full screen anymore on snow leopard. Neither by cmd-F nor by the menu. When I find time, I can look and test myself. But maybe you know immediately were to look.

Full screen mode is currently disabled in the 64-bit build. I was actually going to ask you to test whether it works in 32-bit under Snow Leopard; under Lion and Mountain Lion I only get a black full screen and a log full of GL framebuffer errors.

I’m currently working on refactoring full screen mode to support two different approaches for 64-bit on different OS versions and something similar to the old approach in 32-bit.



Leaving it as it was isn’t an option, since the Mountain Lion dev tools don’t have a 10.6 SDK and the GL errors occur when linking against the 10.7 SDK (regardless of deployment target).

My goal is to support system-standard full screen window mode in Lion and Mountain Lion and a simpler full screen window mode that looks a lot like the current approach in 64-bit Snow Leopard. (Possibly also using that mode in Lion with multiple monitors, for Reasons.)

Edit: to clarify, the current code (as of r5180) works in 32-bit mode when built with 10.7 dev tools targeting the 10.6 SDK. When built against the 10.7 SDK, as required by Xcode 4.4, I get the OpenGL errors. What I’d like testing of is the 32-bit version of the next nightly (Get Info in Finder and select “Open in 32-bit mode”).

[Eric Walch]

Edit: to clarify, the current code (as of r5180) works in 32-bit mode when built with 10.7 dev tools targeting the 10.6 SDK. When built against the 10.7 SDK, as required by Xcode 4.4, I get the OpenGL errors. What I’d like testing of is the 32-bit version of the next nightly (Get Info in Finder and select “Open in 32-bit mode”).

I think two weak ago I needed for the first time a 10.7 SDK during building but I could download one.

To the testing with r5181:

Latest log with Snow leopard:

Code: Select all

Opening log for Oolite version 1.77 (x86-32 test release) under Mac OS X Version 10.6.8 (Build 10K549) at 2012-08-13 23:12:40 +0200.
Machine type: iMac10,1, 4096 MiB memory, 2 x x86 (Penryn) @ 3060 MHz.

Opening log for Oolite version 1.77 (x86-64 test release) under Mac OS X Version 10.6.8 (Build 10K549) at 2012-08-13 23:15:06 +0200.
Machine type: iMac10,1, 4096 MiB memory, 2 x x86 (Penryn) @ 3060 MHz.

In 64 bit I could not enter full screen at all. In 32 bit mode I could enter full screen only by menu, not by keys. Returning back to windowed mode with keys was no problem. The screen content itself seems to be as always.

I also tested it on my other computer that runs under Leopard:

Code: Select all

Opening log for Oolite version 1.77 (x86-32 test release) under Mac OS X Version 10.5.8 (Build 9L30) at 2012-08-13 23:18:52 +0200.
Machine type: iMac9,1, 4096 MiB memory, 2 x x86 (Penryn) @ 2660 MHz.

Strange thing on startup was that I did not get a question to load a saved game. I only could start a new commander.
Entering full screen with keys also did not work, but by menu, it crashed Oolite with the following backtrace.:

Code: Select all

Thread 0 Crashed:
0   libobjc.A.dylib               	0x94b83688 objc_msgSend + 24
1   org.aegidian.oolite           	0x0019360b -[OOMacLegacyFullScreenController setFrameAction:] + 55
2   org.aegidian.oolite           	0x001927cb -[OOMacLegacyFullScreenController runFullScreenModalEventLoopWithFrameAction:] + 207
3   org.aegidian.oolite           	0x00191747 -[GameController(FullScreen) goFullscreen:] + 132
4   com.apple.AppKit              	0x92634e8f -[NSApplication sendAction:to:from:] + 112
5   com.apple.AppKit              	0x926e3b64 -[NSMenu performActionForItemAtIndex:] + 493
6   com.apple.AppKit              	0x926e3869 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 220
7   com.apple.AppKit              	0x926c04ba AppKitMenuEventHandler + 6608
8   com.apple.HIToolbox           	0x93d5b13d DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1181
9   com.apple.HIToolbox           	0x93d5a57b SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 405
10  com.apple.HIToolbox           	0x93d76ecc SendEventToEventTarget + 52
11  com.apple.HIToolbox           	0x93dab1e7 SendHICommandEvent(unsigned long, HICommand const*, unsigned long, unsigned long, unsigned char, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) + 411
12  com.apple.HIToolbox           	0x93dd1959 SendMenuCommandWithContextAndModifiers + 59
13  com.apple.HIToolbox           	0x93dd1914 SendMenuItemSelectedEvent + 134
14  com.apple.HIToolbox           	0x93dd182a FinishMenuSelection(MenuData*, MenuData*, MenuResult*, MenuResult*, unsigned long, unsigned long, unsigned long, unsigned char) + 162
15  com.apple.HIToolbox           	0x93dae494 MenuSelectCore(MenuData*, Point, double, unsigned long, OpaqueMenuRef**, unsigned short*) + 640
16  com.apple.HIToolbox           	0x93dade7f _HandleMenuSelection2 + 383
17  com.apple.HIToolbox           	0x93dadcf3 _HandleMenuSelection + 53

But, maybe that was to be expected with the changed compiler settings?

[JensAyton]

I think two weak ago I needed for the first time a 10.7 SDK during building but I could download one.

Changing to 10.6 SDK shouldn’t be a problem, it just doesn’t exist in Xcode 4.4. My policy has always been that the game needs to build “out of the box” with current dev tools to avoid project rot.

To the testing with r5181:

To reiterate, I’d like to see the result of testing with the nightly build from my machine, but this is interesting too.

In 64 bit I could not enter full screen at all.

This is expected.

In 32 bit mode I could enter full screen only by menu, not by keys. Returning back to windowed mode with keys was no problem. The screen content itself seems to be as always.

The keyboard shortcut has changed, were you using control-command-F? (That reminds me, the shortcut for switching out hasn’t changed, but the current code implicitly supports both control-command-F and command-F so that’s OK.)

Strange thing on startup was that I did not get a question to load a saved game. I only could start a new commander.

This is probably because of a change Kaks made: it only offers to load a game if the default oolite-saves directory exists. I was never entirely convinced.

Entering full screen with keys also did not work, but by menu, it crashed Oolite with the following backtrace.:
…
But, maybe that was to be expected with the changed compiler settings?

No, this was me assuming blocks were available in Leopard when in fact they aren’t (without using a third-party runtime). This will be fixed soonish.

[Eric Walch]

To reiterate, I’d like to see the result of testing with the nightly build from my machine, but this is interesting too.

Yesterday there was not yet a new nighty, but I got it this morning.

The keyboard shortcut has changed, were you using control-command-F? (That reminds me, the shortcut for switching out hasn’t changed, but the current code implicitly supports both control-command-F and command-F so that’s OK.)

I should have noticed the slight change in the menu. The screen drawing is as always on my machine. I encountered some bugs though.

After some switching actions between full screen and windowed mode I tried to launch in full screen mode. I was launched but the screen was not updated en I saw a flickering docked screen. Switching to windowed mode have me the in-flight screen back. In the log I noticed some lines that were logged well before the willLaunch Handler.

Code: Select all

[unclassified]: Current OpenGL context: <NSOpenGLContext 0xb7e280>
[unclassified]: Current OpenGL context: <NSOpenGLContext 0x16bedf40>
[unclassified]: Current OpenGL context: <NSOpenGLContext 0x17041a00>
[unclassified]: Current OpenGL context: <NSOpenGLContext 0x1e7e4d00>
[unclassified]: Current OpenGL context: <NSOpenGLContext 0x1e73e800>
[unclassified]: Current OpenGL context: <NSOpenGLContext 0x1705a0c0>
[unclassified]: Current OpenGL context: <NSOpenGLContext 0x1e73e800>
[unclassified]: Current OpenGL context: <NSOpenGLContext 0x1abc6260>

I could not reproduce the problem again and also did not see those log lines again.

Than there is a problem with quitting in full screen mode. ⌘-Q is not recognised. Or better it is recognised but not acted upon. As soon as I switch to windowed mode after that action, the game does quit.

Starting up in full screen also did not work. With 1.76 I have a windowed screen on startup until the spinning cobra is drawn Than the screen switched in full screen mode. In the nighty this never happens.

This is probably because of a change Kaks made: it only offers to load a game if the default oolite-saves directory exists. I was never entirely convinced.

There was a oolite-saves directory on that computer but it was just not reading the preferences correctly I assume. I also noticed the Oolite app did not show up with an icon. I first launched Oolite remotely over the network from my Leopard computer. That worked, except from the quirks. Than I copied Oolite also to that computer, with the same result. I did run 1.76 from that computer without any problems. I assume the launching over the network started the confusion about the preferences

[Eric Walch]

I forgot the most important test:

Changing full screen resolutions in the preferences no longer works. I can select other resolutions, but I keep seeing the same resolution.

When I set the resolution low with a 1.76 version and open again with the latest version, I do get the low resolution, but changing preferences has also no effect in changing it.


The new key to enter full screen mode will take some time before I get accustomed to it. I read in the apple docs that the new one if the preferred shortcut though. (starting with Lion?)

2) Add an "Enter Full Screen" menu item to the View menu. If you don't have a View menu, the Window menu is a good alternative. Interface Builder provides you with a template "Full Screen Menu Item". Specifically it has "toggleFullScreen:" as the action, and nil as the target. The short cut is "Ctrl-Command-F".

[JensAyton]

I forgot the most important test:

Changing full screen resolutions in the preferences no longer works. I can select other resolutions, but I keep seeing the same resolution.

When I set the resolution low with a 1.76 version and open again with the latest version, I do get the low resolution, but changing preferences has also no effect in changing it.

This is also expected, the responsibility for handling the preferences is being shuffled around. This is the easy part, it just needs other stuff rewritten first. :-)

[JensAyton]

The 10.5 crash should be fixed in r5182.

[JensAyton]

As of r5188, full screen mode is remembered across sessions again. In 64-bit, full screen still doesn’t work but the Enter Full Screen menu item becomes Exit Full Screen when nominally full screen. The rest of tonight’s flurry of changes is all internal structure.