December 15, 2018
Archives  News  Westlake on Alice Requirements, OS X, Demo  Comments  

Westlake on Alice Requirements, OS X, Demo
Monday, April 23, 2001 6:00 AM | Andy Largent
Back   Return to article

GL fullscreen issues
Brad Oliver April 24 - 11:19 PM

Here goes, in no particular order.

In AGL, sending in a refresh rate of "0" to signify the default often gives a failure, depending on some unknown combination of setups. I've found we had to manually specify a range of "known good" refresh rates. When one succeeds, the app fires off an e-mail to me to order me to drink a beer in celebration. :-)

Further to that, if you have a two+ monitor setup, you can never get a valid fullscreen context through AGL. I'm on a 2-monitor machine, so that took me a long time to figure out. Now I just unplug it when I use GL in X. I'd be interested in knowing if it works using the NS gl path; I suspect it's specific to AGL.

Moving on, if you can't find a valid AGL fullscreen context, your next best bet is to create a fullscreen blanking window and attach the GL drawable to that. For the most part, that works even if it's a bit slower and requires a bit more care to program around.

Related to that, if you're on a two-monitor system, you need not only a blanking window for the desktop but another one the size of the device you're rendering to. Attaching a gl context to a window spanning two monitors is obviously not optimal. :-)

But what if you want to switch resolutions or bit depth for the fallback "window" case? Then you're at the mercy of CoreGraphics. What I've noticed is that changing the bit depth upon quitting your app can often freak out the window server and either require a restart or force you to log back in. The solution is a bit awkward - don't change the bit depth.

Moving on, the beachball cursor is rendered by CoreGraphics in software, so if you're in a fullscreen accelerated mode on the Radeon and the beachball appears for a moment, it looks like a static blob because of the Radeon tiling. I _think_ this only happens to Carbon apps that don't use Carbon events, but I'm not sure. It doesn't happen all that often.

Another fullscreen treat: if your app somehow tanks when in a GL fullscreen mode, pressing the force-quit key combo brings up the dialog but you cannot see it. I should try this with the Cocoa FAKK2 app and see if it applies to the NS fullscreen GL stuff as well (I suspect it does).

And one last beauty - the nvidia drivers, when using the preferred fullscreen context method, have a super-bad page flipping bug. One good frame, one frame of stale or partially rendered data. Oy vey.

On the plus side, I don't expect these issues to remain a concern for very much longer. Lest anyone get the wrong idea, Apple's been working pretty closely (and quickly) to help sort through them all.


Fullscreen problems?
Wil Shipley April 24 - 10:41 PM

What problems are you seeing, Brad? We've seen a couple of glitches in Oni under Cocoa (but nothing we considered show-stopping), but then again we haven't tested on as wide a variety of hardware as you have. (Specifically, we still don't have any GeForce cards, although supposedly any day now...)

What we've seen is:

a) very occasionally GL just won't start up at all.
b) one in seven or so times the cursor will hang out in the middle of the screen instead of getting hidden.

I'm wondering if the problems you're seeing are in Carbon or GL: I rather suspect most of GL is the same between Cocoa and Carbon, so maybe it's in the Carbon go-to-fullscreen APIs? You guys are probably about the first to exercise those.


Good point
Brad Oliver April 24 - 12:51 AM

Your point about a new paradigm is well taken. However, Apple has provided us with calls specifically for the purpose of going fullscreen under X. The option exists in Alice to run in a window or fullscreen, so from my standpoint, I see no issues with allowing someone to switch the app out.

My only concern is that the functionality that is provided by Apple for fullscreen leaves a less-than-favorable impression at the moment under OSX. Ultimately, the desirability of that feature as relates to games should be determined by gamers. If they want their apps to be able to run fullscreen, games need to be able to handle that properly.


A different paradigm
Michael Eilers April 23 - 11:15 PM

I think Mac gamers and developers need to take a step back from Mac OS and think about this a bit -- not directed at you, Brad, but at the overall concept of the Mac OS. The truth is, Mac OS X is different -- radically so -- not just in structure but in paradigm. The OS itself is designed expressly for the purpose of doing many things at once and doing them all well. Thus dedicating the system to just a single, monolithic task no longer makes as much 'sense' as it used to. If I can download files and check my e-mail and surf the web and play a game at the same time, does making the game take over the screen really benefit the gamer and fit the OS?

Mac OS X will never be a "gaming OS" -- a gaming os runs on a console. Mac OS X does MUCH more than gaming, and games should fit the paradigm, not the other way around.

Full screen
Brad Oliver April 23 - 8:12 PM

1. I think the fullscreen issue is partly bugs in OSX itself and partly that OSX is so different. The OS is so new, I'd be reluctant to place the responsibility on anyone at this point.

2. To the best of my knowledge, Apple is well aware of the issues and are working pretty hard on fixing everything they can from their end. I have no hard info on when, but I would be shocked if it's not all sorted out by MacWorld NY in July. WWDC is coming up shortly, and I suspect when developers and Apple roll up their sleeves and mix it up, we'll all pick up something useful we can apply before July.


Full Screen
JL! April 23 - 3:49 PM

I just want to know 2 things:

1) Who is responsible for fixing the lack of full screen support in OS X, the game writer or Apple or someone else?

2) How hard are they working on this problem? If they're aware of it, when will it be fixed?

It seems to me that this is probably the most important of all OS X gaming issues because running a game in full screen is one of the most basic things that must happen in any game. Non-full screen just isn't "real." Any OS that can't easily run a game written for it in full screen will NEVER be taken seriously as a gaming OS. It has subliminal implications (looks like it's emulating rather than really doing it).

Article Comments Closed

This article is too old to post any new comments too. If you would like to discuss the issues relating to this article, you may do so freely in the Inside Mac Games Forums. Thank You.

News Headlines for Monday, April 23, 2001

GeForce 3 Arrives for PC, First Review 4:43 PM
Marathon: Resurrection Gallery, Site Updates 4:17 PM
New Mac Flight Sim Resource 11:31 AM
Bushfire Updated to 1.07 10:32 AM
Baldur's Gate II Beta Test Reports 10:05 AM
Blizzard Reports Diablo II Bug 9:09 AM
New Fly! II Screens 9:01 AM
Dim3 Progress Update 6:00 AM
Apple Looks at AirPort Gaming 6:00 AM
Westlake on Alice Requirements, OS X, Demo 6:00 AM
OmniGroup Claims Alice Done, EF and FAKK2 Soon 6:00 AM
Quake and Doom Released for OS X 6:00 AM
View all of the news for Monday, April 23, 2001 on one page

Recent News

Friday, April 20, 2001
Thursday, April 19, 2001
Wednesday, April 18, 2001
Tuesday, April 17, 2001
Monday, April 16, 2001

Search for other news stories or browse our News Archive.

Archives  News  Westlake on Alice Requirements, OS X, Demo  Comments