Changing Screen Size/Depth in AGL

Moderator
Posts: 335
Joined: 2002.04
Post: #1
Just thought I'd have a go at setting up Airburst Extreme so that the user can choose what screen resolution they want to run in.

I'm using aglSetFullScreen() after creating a context to create my full screen context at the start of the game, but when I attempt to change the resolution by getting rid of the old context and creating a new one (to the same device) with the same set of commands, the resolution seems to change, but I'm left with a black screen that GL doesn't seem to want to point to anymore (despite using aglSetCurrentContext () ).

Any ideas on what I might be missing out here ?
Quote this message in a reply
Member
Posts: 177
Joined: 2002.08
Post: #2
I think you're supposed to change the display resolution with CoreGraphics, not AGL. Did you capture the display?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
aglSetFullscreen (or whatever it's called) captures the screen for you.
Quote this message in a reply
Moderator
Posts: 335
Joined: 2002.04
Post: #4
Yes, it's capturing the screen ok, but for some reason isn't letting oGL draw to it after it's called a 2nd time.
Quote this message in a reply
Member
Posts: 446
Joined: 2002.09
Post: #5
Quote:aglSetFullscreen (or whatever it's called) captures the screen for you.
It does, but I've found that it's always safer to set the resolution and depth with CG first - before creating the pixelformat - or else AGL can fail. Example: If I set my desktop depth to 16bit on my GF3, then request AGL fullscreen at 32bit, it will crap out (at least last time I tried it did, this may have been fixed in an OSX update since then, but better safe than sorry). You can also do some nice gamma fades with CG instead of the abrupt switch used by AGL fullscreen.

Back to the problem...

How are you destroying the context? Are you trashing and reloading all the textures? Are you sure the new resolution is valid for the device?

It's hard to say what the problem could be without seeing the source, but you should treat it as if the app shutdown and restarted - trash the textures, completely destroy the context and release the screen, then build a new pixelformat and fire it all up from scratch. It doesn't hurt to save a list of valid screen modes to check against either.
Quote this message in a reply
kberg
Unregistered
 
Post: #6
I've had issues using AGL with drawsprockets similar to what you are describing. I've also had AGL and drawsprockets work beautifully in the past for me when switching screen depths and destroying / creating AGL contexts, so you never know I guess Grin

This is my latest setup for AGL. It's an early crack at making CG and AGL work nice together instead of relying on DrawSprockets. This only does fullscreen, no window support. On my iBook, running in 32 bit mode, getting rid of DrawSprockets has actually doubled my framerates with no other code changes! Wow so for me this is definately a good thing.

http://www.sfu.ca/~kberg/Code/Display.h
http://www.sfu.ca/~kberg/Code/Display.cpp

The next feature I was planning to implement was a sort of pixel format preflight that would walk various resolutions and bit depths, generating some sort of data structure of valid resolutions beforehand. This way I could create a list of only valid bit depths / resolutions for the user to choose from.

I wish I kept a 10.1 machine around to test this out with, but it seems to work ok with my iBook and G4 (both ATi machines though...), so if anyone wants to let me know if I've done anything super stupid...
Quote this message in a reply
Member
Posts: 446
Joined: 2002.09
Post: #7
Quote:Originally posted by kberg
...getting rid of DrawSprockets has actually doubled my framerates with no other code changes!...

Yup... AGL fullscreen is much faster than DrawSprocket's backbuffer on OSX (using the backbuffer is basically like drawing into a window, double-double buffered on OSX). Unfortunately, AGL fullscreen doesn't work with every system configuration (even though it should). Some ATI PCI cards, mult-head systems, and cards attached to LCD's will fail to return a fullscreen pixelformat, so you should try AGL fullscreen first, then drop into the slower DrawSprocket/backbuffer path if it fails. (I think Apple may have fixed a couple of these cases recently with 10.2.4)

I've ended up writing a CGL path for fullscreen on OSX in hopes of avoiding DrawSprocket all together, but I haven't had a chance to test it on anything but a GF3/2MX (where AGL works anyway) so similar problems may exist here as well.

Quote:Originally posted by kberg
...The next feature I was planning to implement was a sort of pixel format preflight that would walk various resolutions and bit depths, generating some sort of data structure of valid resolutions beforehand...

That's always a good idea, especially to ensure valid refresh rates (games at 60Hz hurt my head) and to support odd-ball wide-screen resolutions. I have C sources that do this if you need some tips (through CG for OSX, and DSp for classic - even a DisplayManager version from way-back when...)
Quote this message in a reply
Moderator
Posts: 335
Joined: 2002.04
Post: #8
I'm using RezLib to get my valid list of screen resolutions etc.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Changing Pixel Values using CG LIPH700 1 4,673 Nov 25, 2010 03:17 PM
Last Post: SethWillits
  OpenGL full screen mode leaves garbage on screen when exiting app Malarkey 5 5,418 Nov 19, 2008 12:51 PM
Last Post: Malarkey
  Changing resolution while already in full-screen mode? Malarkey 1 2,729 Jun 10, 2008 07:49 PM
Last Post: AnotherJake
  Effifcient State Changing Nick 7 3,672 Apr 6, 2006 06:33 AM
Last Post: TomorrowPlusX
  Changing the Mask in OpenGL kodex 2 3,887 Jan 18, 2006 09:21 PM
Last Post: kodex