What's with all these fullscreen games?

The sample code you posted for switching fullscreen and back seems to be Carbon based.

How do I do this from Cocoa?

Sorry for asking but no experience at all of Carbon as Cocoa and Objective-C is the only development I've done on Mac since switching from Windows.

There is no Cocoa. AppKit depends on a windowed environment, you know, for events and stuff. I guess they could have added wrappers to Foundation somewhere, but that's a waste of time. REMEMBER: Objective-C is C with objects, so you better understand functions, too. Core Graphics is worth knowing.

The sample project from NeHe that skyhawk links to above incorrectly sets up the fullscreen context-- it fails to specify the display to use, so it doesn't work on Powerbooks or other multi-display systems.

It also captures the screen before realizing it has failed, so it flashes everything black.

The reason why so many developers go fullscreen-only is shown by the confusion displayed over fullscreen in this thread. Display modes have always been a moving target on the Mac, from doing it yourself with the Display Manager, to DrawSprocket, to QuickTime, etc. There are OS 9 vs OS X differences in how to do things best, window buffering vs lack of window buffering, third party tools like Ian Ollman's library or SDL, sample code from Apple that doesn't always work or which is not documented properly, menubar drawing or lackthereof, Cocoa vs Carbon APIs, multiple monitor support, etc.

Getting a good game out there is hard enough as it is. Every single time that you deal with OS specific issues, you are taking time away from your actual game development, and opening yourself up to OS specific issues of checking for software versions, misfeatures, bugs, gotchas, video incompatibilities, workarounds, speed, etc.

And then there is maintenance and support. Not trivial.

I've done both fullscreen only, and windowed, and combined. I use windowed mode for development, but I don't demand that arcade style games use a windowed mode. Board and some puzzle games are different, obviously.

Games really are a special case, at least for fast action games. They do not fit in with the desired Apple event model, because they really DO want to hog system resources for maximum performance. If you can provide a windowed mode, great, if not, well, life is short, and video games are expensive to produce at the best of times, without having to worry unduly about platform specific stuff.

I will say, however, that for development, I consider it vital to have a windowed mode, however spotty it is. You are doing yourself a major disservice if you don't have a console or text file that you can write errors or status reports to in real time as you test your game and develop content for it. I wouldn't even contemplate developing a game in fullscreen mode alone.

Heh. When I had a problem with my fullscreen game (it was a choice: either windowed or fullscreen, and the crash happened only during fullscreen) I fired up my Linux server next to it, ssh'ed into my main dev machine, and ran GDB so that the GDB output was showing on one machine while the other played the game

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?

I can't see any reason not to support both modes - at least not in any design that I am currently working on.

Take, for instance, a turn-based puzzle game. You might want to have it running behind all the windows while doing a spreadsheet, and sometimes popping it to the front to do a few moves. Still, it might be a lot more immersive to play in fullscreen. I'm just echoing what others said here...

But, for instance, El Ballo (a 2D platformer I'm working on) will support both modes too, even though it's an action game. It's simple to play nice with the other apps - just pause the game when it is switched to the background/suspended. I can think of a few situations when a player might want to run in a window: a modem user doing a download - he might want to play a game, and still keep an eye out for when the d/l is finished. Copying files, burning CD:s and such. OS 9 users might want to run in a window, since a lot of games mess up the desktop when they switch resolutions.

But, still, I think that running games in a window works best for small games - games that doesn't run on a 800x600 arena. Look at the game Down&Out. It's roughly 300x250 in a window, and it fits neatly on the desktop, among other windows and apps, and that's actually it's strength - that it doesn't get in the way of what you're doing.

Oh, yeah, as for solutions to the problem: in El Ballo, I came up with an approach that works quite nicely:

Whenever the game is paused, the window is hidden/fullscreen is disabled, returning everything to it's non-game state. Then, I put up a small (100x150 or something) window, with a small graphic and a message that says that the game is paused. In addition to that, two Aqua buttons labeled "Quit" and "Resume", the latter defaulted. Now, the player pauses, everything goes away, but there's one little, non-cluttering window left to ease the process of finding it again. (Many newbie computer users seem to have a hard time to resume programs that's just a menu bar and a Dock icon - they can't find it.) The window is closable and minimizable, so it can be put out of the way totally, if need be. To resume the game, the player just needs to click the little window, and hit return or click the resume button to get back, or click the quit button to insta-kill the app, no questions asked, no screen fades, no resolution switches, no nothing.

I'm very satisfied with this solution, since it allows me to put the game away completely while not losing it. Also, sometimes, when a game is paused and you decide you don't want to play it anymore, you want to kill it without having to get back into the old display mode and work yourself out of the game the hard way.

Now, the thing I like best about this solution is that it's completely moduled. The way it's built around my GameApp class, it's just a matter of updating the .nib with a new graphic and I can put the same solution into any game in under two minutes. Me like!

I throw in two screeners here, and hoping that Casey won't rip out my lungs for showing graphics early... :/