What's with all these fullscreen games?

Feanor
Unregistered
 
Post: #46
Quote:Originally posted by BeyondCloister
OneSadCookie,

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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #47
CoreGraphics is not part of either Carbon or Cocoa.

There is no Objective C API for going full-screen, because as FÎanor mentioned, AppKit is an application framework, not a game framework.

You can find DisplayKit on the web, it's an Objective C wrapper for the CGDirectDisplay functionality. Personally, I think it's almost easier just to use CGDirectDisplay straight, but YMMV.
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #48
Download this

this has an example of how to do fullscreen... it uses coregraphcis and all, but it shows you how to do everything for an opengl type window.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #49
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.

Correct method of setting up fullscreen explained in this thread
Quote this message in a reply
Member
Posts: 31
Joined: 2004.09
Post: #50
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.
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #51
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 Wink

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?
Quote this message in a reply
Oldtimer
Posts: 832
Joined: 2002.09
Post: #52
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... Smile

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.
Quote this message in a reply
Oldtimer
Posts: 832
Joined: 2002.09
Post: #53
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! Grin

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

Window plays nice
Window sits in Dock
Quote this message in a reply
Member
Posts: 164
Joined: 2002.04
Post: #54
That's very slick; I wish I knew how to do that Rasp
Quote this message in a reply
Oldtimer
Posts: 832
Joined: 2002.09
Post: #55
I might take up on Carlos' suggestion and write something up on this subject...

David, if you want instructions, just mail me off the list: ivan at rusted dotcom.
Quote this message in a reply
Post Reply