Best way to switch screen res?

[ChrisD]

Hi

What is the best way to switch screen res for a game that does not use opengl?

Im using CoreGraphics right now....
Which moves the users windows a round. :mad:

Other ideas?

[OneSadCookie]

Always capture the display before changing resolution.

[ChrisD]

Originally posted by OneSadCookie
Always capture the display before changing resolution.

And how would one go about this?

AKA... what API etc am I looking for?

[FCCovett]

Had you downloaded the source, you would have known it by now. :)


void SwitchMainDisplayResolution()
{
CGDisplayCapture( kCGDirectMainDisplay );

//----------------------------------------------------------------------
// Try to switch to a display mode with resolution 640 x 480,
// depth 32 bpp, and refresh rate 60 hertz:

CFDictionaryRef displayMode;

//----------------------------------------------------------------------

displayMode = CGDisplayBestModeForParametersAndRefreshRate(
kCGDirectMainDisplay,
32,
640, 480,
60,
NULL
);

//----------------------------------------------------------------------

CGDisplaySwitchToMode( kCGDirectMainDisplay, displayMode );

//----------------------------------------------------------------------

CGDisplayRelease ( kCGDirectMainDisplay );
}

[ChrisD]

Originally posted by FCCovett
Had you downloaded the source, you would have known it by now. :)


You mean...
If I had bothered to actually look at the source ;)
Had not the time yet...
On phone with apple trying to get a iBook fixed. ugg

Any how thanks much... will try this tonight.

[OneSadCookie]

There is a problem on Panther with capturing a single display (search mac-opengl and/or mac-games-dev for the thread).

I've always used CGCaptureAllDisplays anyway -- I think it's a better user experience.

[AnotherJake]

Yeah, and it STILL doesn't work right 100% of the time with multiple monitors. Grrrrr...

[aarku]

Alternatively, check out ModeWhacker (http://developer.apple.com/samplecode/Sample_Code/Graphics_2D/ModeWhacker.htm). I modified the main like this to capture the displays. It leaves your windows alone!

-Jon

int
main(int argc, const char *argv[])
{
CGDirectDisplayID display[kMaxDisplays];
CGDisplayCount numDisplays;
CGDisplayCount i;
CGDisplayErr err;

err = CGGetActiveDisplayList(kMaxDisplays,
display,
&numDisplays);
if ( err != CGDisplayNoErr )
{
printf("Cannot get displays (%d)\n", err);
exit( 1 );
}
printf( "%d displays found\n", (int)numDisplays );

err = CGCaptureAllDisplays();
if ( err != CGDisplayNoErr )
{
printf("Cannot capture all displays (%d)\n", err);
exit( 1 );
}

for ( i = 0; i < numDisplays; ++i )
{
modewhacker(display[i]);
}

err = CGReleaseAllDisplays();
if ( err != CGDisplayNoErr )
{
printf("Cannot release all displays (%d)\n", err);
exit( 1 );
}

exit(0);
}

[aarku]

Originally posted by FCCovett
Check out the source from this thread (make sure to use the most recent link - the web-site with the source has moved):

http://www.idevgames.com/forum/showthread.php?postid=51277#post51277

I tried that out, and I uncommented all the screen changing stuff from your main to try that out. It didn't work. (Windows got resized and for some reason the menu bar in Xcode got screwed up and I had to relaunch Xcode) If you plan on updating MyGame, I'd suggest putting in a Fullscreen menu option.

-Jon

[AnotherJake]

Originally posted by aarku
Alternatively, check out ModeWhacker (http://developer.apple.com/samplecode/Sample_Code/Graphics_2D/ModeWhacker.htm). I modified the main like this to capture the displays. It leaves your windows alone!

-Jon
It works perfectly so far! You get a star!

I'm still skeptical though... I just KNOW I'll find more junk if I beat it up enough.:)

Thank you.

[ChrisD]

Modewhacker

Ah perfect I never noticed the screen capture part of that app.

I think my code was based on it

[ChrisD]

Ok another issue

calling CGCaptureAllDisplays();

Works fine.

Except that none of my previouse window code seems to work at all... windows do not draw etc...
or in this case dialogs read from res files.

Any thought?

Do I need to some how bless the current window.

Im looking through code and not noticing anything.

[AnotherJake]

Okay, after all these years of programming on Macs since system 7, I'm going to just blow a gasket on this one. ENOUGH!!! This screen/pixel/capturing/context/port thing has gone on long enough! When will they (Apple) put somebody in the seat that can make it simple and straight-forward? Why do we constantly have to fight with this? I can't possibly count the number of different hoops I've had to jump through with every single fudsing release FOR THIRTEEN YEARS to get this simple task accomplished! End gasket blowing. Sorry.

Should we start a petition?

[ChrisD]

Originally posted by AnotherJake
Okay, after all these years of programming on Macs since system 7, I'm going to just blow a gasket on this one. ENOUGH!!! This screen/pixel/capturing/context/port thing has gone on long enough! When will they (Apple) put somebody in the seat that can make it simple and straight-forward? Why do we constantly have to fight with this? I can't possibly count the number of different hoops I've had to jump through with every single fudsing release FOR THIRTEEN YEARS to get this simple task accomplished! End gasket blowing. Sorry.

Should we start a petition?

No No it is perfectly fine to feel that way...
Im on liek 10+ years of mac game programming and damn if that was not always one of the biggest pain in the ass issues I ever had to deal with on the mac :-)
So I feel your pain...

[Frank C.]

Originally posted by ChrisD
Except that none of my previouse window code seems to work at all... windows do not draw etc...
or in this case dialogs read from res files.
They're drawing just fine, they're just _under_ the CoreGraphics blanking window.

I hacked around this in a REALBasic plugin: <http://webhome.idirect.com/~frankco/rb/downloads/DisplayOverlord_v10b1.sit> full source is included (it's CFM Carbon but will work in Macho as-is - just ignore the runtime glue). One problem I haven't been able to solve is that Carbon has no concept "menu" windows, so they still draw under the blanking window (if you can avoid popup menus in your GUI you should be fine, otherwise you might need to use Cocoa).

[FCCovett]

Originally posted by Frank C.
(if you can avoid popup menus in your GUI you should be fine, otherwise you might need to use Cocoa).

I saw another posting here about this same issue. You just need to resort to SetWindowGroupLevel() with kCGMaximumWindowLevel and your "handmade" contextual menu pop-up windows will draw on top of the blanking window.

[Frank C.]

Originally posted by FCCovett
I saw another posting here about this same issue. You just need to resort to SetWindowGroupLevel() with kCGMaximumWindowLevel and your "handmade" contextual menu pop-up windows will draw on top of the blanking window.
Not sure what you mean by "handmade" - can you give more details?

[FCCovett]

The answer would be to create a window to serve as a pop-up menu and promote its level so it shows in front of the blanking window.

The tough part is to code all the elements for that window to look and act as a pop-up menu, but it can be done. I am not aware of an alternative way to do this, but there may be one.

I've heard something about drawing directly to the blanking window being slower than drawing to a newly created window positioned on top of the blanking window. Also, drawing with Quartz2D to the blanking window is not automatically double-buffered (at least not on my computer). Any insight on these issues?

[codemattic]

FYI - on behalf of AnotherJake I deleted a couple of posts in this thread that resulted from a miscommunication.

[Frank C.]

Originally posted by FCCovett
...The tough part is to code all the elements for that window to look and act as a pop-up menu, but it can be done. I am not aware of an alternative way to do this, but there may be one.

I was afraid that's what you meant :( . I think it *may* be possible to this in Cocoa, since it has a value for NSPopUpMenuWindowLevel that's mysteriously missing from CGWindowLevel.h... I haven't had time to experiment with it though.

Originally posted by FCCovett
I've heard something about drawing directly to the blanking window being slower than drawing to a newly created window positioned on top of the blanking window.
That sounds odd (Apple recommends doing just that). I've drawn to it with OpenGL in the past on systems where AGLFullscreen fails (via DSpContext_GetFrontBuffer), and although it is slower than AGLFullscreen, I found it to be basically identical in speed to a totally separate window. Never tried QuickDraw/Quartz though.