Using second monitor on Mac OSX Snow Leopard
Posted Wednesday, 4 November, 2009 - 18:23 by VeliV| Project: | The Open Toolkit library |
| Version: | 1.0-beta-2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
The following code:
class MyGame : GameWindow { public MyGame() : base(width, height, GraphicsMode.Default, "title", DisplayDevice.AvailableDisplays[1]) { } }
Creates the GameWindow on the same device as default. So changing the displaydevice has no effect on Mac OSX. Using the latest versions of the OSX on the following setup:
# 2.8GHz Intel Core 2 Duo
# 4GB 1066MHz DDR3 SDRAM - 2x2GB
# NVIDIA GeForce 9400M + 9600M GT with 512MB
Comments
#1
Forum topic about the issue.
#2
We need to bind and call CGDisplayBounds to get the actual bounds of the display.
#3
This was something I never implemented, because I had no way to test it out. Particularly if one wants to go full screen with a context, a display device must be specified when the context is created. It looks like the API has changed though, to allow specification of a display device when creating a graphics context. In that case, one needs to modify the call to DMGetGDeviceByDisplayID in AglContext.cs.
#4
If you tell me preciscely what you need to change there I can test it out and report back :)
#5
Ok, I think I've fixed this in rev. 2481. It should now detect the proper bounds for the specified device. If it doesn't work, can you add the following line to the beginning of your code (before OpenTK is initialized or anything in OpenTK is used), and post the output?
Also, I have included a hack in rev. 2482 to allow OpenTK to specify the device to AGL that was used to create GameWindow. This should allow one to have a full screen context on a specified display device, if you could test that too I'd appreciate it.
The "correct" way to do this would be to specify the device to the GraphicsContext constructor, but I'm not sure it's worth changing the API at that level when this sort of hack should work fine.
#6
I am marking this as fixed, but please reopen if the issue remains in 1.0 beta-2.
#7
Closing issues fixed in 1.0 beta-2.