BeginFullScreen moving windows around

[Rasterman]

I think I am calling BeginFullScreen and more importantly EndFullScreen correctly, but my other windows and desktop are little different than before the call, can anyone see anything wrong with my code?

I am calling SwitchToResolution just after the following code

_hwnd = NewCWindow(nil, &r, "\p ", true, windowtype, (WindowPtr)-1, true, 0);
setTitle( windowName ) ;
if ( _hwnd == NULL ) return false ;


ShowWindow( _hwnd ) ;

SetPortWindowPort( _hwnd ) ;
BringToFront( _hwnd ) ;
HiliteWindow( _hwnd , true ) ;


bool SwitchToDepth(short depth)
{
GDHandle gd = GetGDevice();
VDSwitchInfoRec screenInfo ;
if(gd && DMGetDisplayMode ( gd , &screenInfo ) == noErr )
{
if ( screenInfo.csMode != depth )
{
SetDepth(gd,depth,0,0);
}
}
else
{
SetDepth(gd,depth,0,0);
}
}


bool SwitchToResolution(short width, short height, short depth)
{
printf("switching resolution to %dx%dx%d\n", width, height, depth);

SwitchToDepth(depth);

Ptr restoreStateNow =0;
short pwidth, pheight;
pwidth = width;
pheight = height;

//BeginFullScreen(&restoreState, GetGDevice(), &pwidth, &pheight, &_hwnd, 0, fullScreenHideCursor);
BeginFullScreen(&restoreStateNow, NULL, &pwidth, &pheight, NULL, 0, 0);
if(!restoreState)
restoreState = restoreStateNow;

MoveWindow(_hwnd, 0, 0, true);
SetPortWindowPort( _hwnd ) ;
BringToFront( _hwnd ) ;
HiliteWindow( _hwnd , true ) ;

ChangeWindowAttributes(
_hwnd,
0,
kWindowStandardHandlerAttribute | kWindowCloseBoxAttribute | kWindowCollapseBoxAttribute
);

//SetWindowClass(_hwnd, kPlainWindowClass);

return true ;
}


void RestoreResolution( void )
{
if ( restoreState == NULL )
return ;

printf("restoring resolution\n");

EndFullScreen( restoreState , 0 ) ;
restoreState = NULL;

long wx = (desktopWidth - _windowWidth)/2 ;
long wy = (desktopHeight - _windowHeight)/2 ;
MoveWindow(_hwnd, wx, wy, true);

//ChangeWindowAttributes(_hwnd, 0, kWindowNoTitleBarAttribute | kWindowNoShadowAttribute);
SetWindowClass(_hwnd, kDocumentWindowClass);

ChangeWindowAttributes(
_hwnd,
kWindowStandardHandlerAttribute | kWindowCloseBoxAttribute | kWindowCollapseBoxAttribute,
0
);
}

[AnotherJake]

Have you tried adding fullScreenCaptureAllDisplays to your flags for BeginFullScreen?

[Rasterman]

I haven't, but that flag doens't sound like what I want to do, when running a fullscreen game do most games blank out the other displays? I certainly don't want to block the Command+Tab key.

fullScreenCaptureDisplay - this flag causes QuickTime to capture the display being used for full-screen through the use of CGDirect Display. Capturing the display prevents contention for the screen from other applications and system services. This doesn't look any different, but it will block the Command + Tab key.

fullScreenCaptureAllDisplays - this flag is similar to the fullScreenCaptureDisplay flag except it will blank out all displays connected to the system, not just the one you are drawing to. This is visually similar to what is seen when iTunes switches to full-screen visualization mode.

[AnotherJake]

I haven't, but that flag doens't sound like what I want to do, when running a fullscreen game do most games blank out the other displays? I certainly don't want to block the Command+Tab key.

You might not have any choice. I have to specifically implement cmd-tab myself in full screen because... you have to *capture* the display(s) before switching to full screen mode if you don't want your desktop icons and windows to get screwed up. I know it doesn't say that in the description, but it's pretty well known behavior. I haven't used BeginFullScreen, so that's why I asked if you tried. If that doesn't work, then you should probably use the CG routines yourself instead of going through Quicktime. I would have used the CG routines to begin with myself.

BTW, you can just capture one display if you want. I usually do all of them, but it's your call.

[Rasterman]

I see what you are saying. Well, both fullScreenCaptureDisplay and fullScreenCaptureAllDisplays dont change the resolution at all.

I hate how almost every link to apples help files is moved and invalid now.

I am looking at the CG stuff now, is this good code to follow?
http://developer.apple.com/technotes/tn/tn2007.html

[AnotherJake]

That page says it's a legacy document, so I'd say no. Trying to figure out the right path through Apple docs alone can be quite a task for this particular matter. I would suggest trying OneSadCookie's book first: http://onesadcookie.com/book

[AnotherJake]

Here is some better ADC documentation for you: http://developer.apple.com/documentation/GraphicsImaging/Conceptual/QuartzDisplayServicesConceptual/

[ThemsAllTook]

I hate how almost every link to apples help files is moved and invalid now.
That's probably because they're focusing most of their efforts on Cocoa nowadays, with plans to phase out Carbon sometime in the distant future. The APIs you're using are pretty out of date... I know it's a painful process, but you might want to try modernizing a bit. Cocoa is really nice once you learn to work with it.

[Rasterman]

That page says it's a legacy document, so I'd say no. Trying to figure out the right path through Apple docs alone can be quite a task for this particular matter. I would suggest trying OneSadCookie's book first: http://onesadcookie.com/book

Thanks, I'll try the fullscreen section code on Monday :D

[Rasterman]

I tried the code in fullscreen section in http://onesadcookie.com/CreatingMacGames/CreatingMacGames.pdf it switches resolutions and captures the display correctly, but for some reason my bit copying code that copies the image to the window isn't working when it goes into full screen, to copy my data to the window I am calling QTNewGWorld, GetGWorldPixMap, LockPixels, then doing a memcpy directly to (*pm)->baseAddr.

The resolution switches happen after the LockPixels call, so is the PixMapHandle invalid after the call to CGDisplaySwitchToMode?

[AnotherJake]

Gosh, I really haven't a clue, although I wouldn't touch anything that says GWorld in it with a ten foot pole. Plus, as far as I know, the only way to get rid of a GWorld is with DisposeGWorld, which is deprecated, even though QTNewGWorld isn't for some reason. QuickDraw is officially deprecated in 10.4, so you shouldn't be developing any new software with it. Use Quartz instead.

As far as I am aware, all of us around here use OpenGL for rasterization. I am not aware of any other more efficient way to `blit' on OS X, other than through an OpenGL texture. With OpenGL you can get an automatic DMA boost when moving pixels to screen via a texture. Plus it can automatically scale any software rendered resolution to fit, which is a bonus.

The watered down version of the way I do it in OpenGL is:
- allocate a buffer (your software frame buffer, or back buffer, or whatever you'd like to call it)
- create an empty OpenGL texture the size of the buffer
- create an OpenGL quad the size of the screen or window
- render the `software' scene into the buffer (the old fashioned way, or with another graphics API, no OpenGL involved at this step)
- call glTexSubImage2D to have OpenGL `blit' it to the screen (OpenGL thinks it's just another texture), which will automatically use DMA whenever possible

So all OpenGL is doing is setting up the graphics environment and drawing a single textured quad for you, and nothing else. I've heard many people run away screaming because they didn't want to learn OpenGL, but doing this technique doesn't really require learning OpenGL except to set up a context (which is covered in OneSadCookie's book) and drawing a quad. It's really pretty simple -- no 3d or anything like that.

[Rasterman]

I know OpenGL quite well and wrote a OGL blitter before trying QuickDraw, it was faster by about 2X, but it wasn't stable across all machines I tested it on, and QD was working well enough, so thats what I went with for my last game port, I may try the OGL one again, but it would be much easier to just get this resolution switching working properly I think.

BTW I am not too worried about using outdated APIs as long as they work as won't they be supported in all future versions of OSX?

[AnotherJake]

BTW I am not too worried about using outdated APIs as long as they work as won't they be supported in all future versions of OSX?
No. Apple has made it abundantly clear that QuickDraw is *no longer supported*. I wouldn't even lay money on QD being in Leopard, although we'll see. It certainly won't be in the 64 bit APIs.

What instabilities did you encounter with OpenGL?

[OneSadCookie]

Apple ain't going to suddenly break backward compatibility, so yes, apps that use QuickDraw that work on 10.4 should work on 10.5.

OTOH, they may remove support in future OS versions (with fanfare to announce that this will be the case), and as Jake says, there won't be 64-bit QuickDraw. QuickDraw-based games will also suffer with the move to high-resolution displays that's presumably coming.

Basically, why write code for a legacy technology that's been loudly and clearly signaled as being a bad idea?

[Rasterman]

Basically, why write code for a legacy technology that's been loudly and clearly signaled as being a bad idea?

Simple, getting 5 lines of fullscreen switching code working properly is a lot easier than 1000+ of new OGL stuff.

[AnotherJake]

Simple, getting 5 lines of fullscreen switching code working properly is a lot easier than 1000+ of new OGL stuff.
Huh? You can do the OpenGL technique I pointed out above in maybe <50 lines.

[Rasterman]

Sorry, I was talking about my base code for my games, it is about 1500 lines, although since neither BeginFullscreen or GD stuff is working properly, OGL is quickly becoming my only option...

[Rasterman]

Well you will all be happy to know I am now using GLUT/GL for my base game stuff, it took about a day of monkeying around but it is working quite nicely now, except for the keyboard controls with GLUT are kind of hacky. Hopefully it holds up when I start testing it on other machines. Right now I'm testing on a MacMini with 10.4.10, 1.66GHz Intel Core Duo, 1 GB 667 DDR2, and a craptastic Intel GMA 950. I am getting about 50fps at 1024x768. Next I need to figure out how to get a list of possible resolutions the game can switch to, I'll post another thread asking that.

Also, what is the install base for OGL and GLUT on Macs? Does OSX come standard with these 2 things installed, I would assume so since this is what everyone is using to make games these days, but I just wanted to make sure?

[AnotherJake]

Yeah, OpenGL and GLUT are standard installed, so no worries there.

Your machine is exactly the same as mine. It seems to be a really good, modern baseline to be developing from. The GMA950 does present a few challenges but it's great that you're developing from it because Apple is selling a LOT of machines with those little buggers in them nowadays.

It's great to hear that you got things working for you with the OpenGL path! Sounds like you're getting pretty decent performance too (assuming you're doing the texture upload thing).

Oh yeah, one more thing: Be sure you are setting it to synch to VBL to avoid visual tearing.