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 ?

I think you're supposed to change the display resolution with CoreGraphics, not AGL. Did you capture the display?

aglSetFullscreen (or whatever it's called) captures the screen for you.

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: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.

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

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! 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: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...)

I'm using RezLib to get my valid list of screen resolutions etc.