I have some code that used to work fine on my old G4 with my GF2MX that now won't work on my new G4 with the GF4MX (and 10.2.6 instead of probably 10.2.3).

Even if I turn off all attributes except the fullscreen one, I get nil back from the initialization. What do I need to do to make this work? I have no problems playing any number of fullscreen FPS games... I do remember a problem with some Carbon ports of Quake not working because they can't find a renderer, but then Cocoa GLQuake works fine.

Does not the pixel format attribute choose other settings according to the default for the simplest or some other best renderer found which matches my request? Why would a fullscreen renderer be unavailable?

The software renderer can't do fullscreen, so if you're falling back to that for some reason you might have problems.

Do you have a second monitor attached somehow?

Is your monitor set to 16-bit color? (shouldn't matter, but I guess it might...)

You'll never get a 32-bit color/16-bit Z on an NVidia card. Does 24-bit Z work?

Do you get non-nil if you just remove the fullscreen attribute? That's implied but not explicit in what you said

Have you tried restricting the renderer to a particular screen?

It's odd, I've got the same system as you, I think, and I'm sure I've had a very similar pixel format work...

On my Radeon, you have to capture the display to make the full-screen formats available.

Mark, I was thinking that that might be a possibility. But that is annoying as heck, because if I want to switch back and forth from full screen, I have to re-generated the context every time. I guess it's a no-brainer since I'm using the view's context as the share context.

I think somebody should point SkyHawk at this thread -- he's probably having the same problem.

OSC, I have a totally vanilla setup: single screen, 32-bit. I tried asking for a renderer with fullscreen and specified nothing else, and still got nil for my pixelformat. The only diff between you and me (inside the computer) is that you have a better video card. I have a GF2, so the need to capture the screen first must not have anything to do with the card?

Anyway, I can probably fix it with this information.

Do you think this is a bug?

EDIT: Still not working when I capture the screen first. I'm going to have to start from scratch, I guess.

IIRC, you can get away with storing the created pixel format or the context (without drawable), releasing the screen, capturing it again later, and then using the stored data.

I have Cocoa code somewhere that can switch between fullscreen and windowed at the touch of a button. Event-handling doesn't work properly in fullscreen mode, but I'll leave that to you to fix

http://203.79.121.211/CVS/

It's called GameShell. You'll need Brian Christensen(sp?)'s DisplayKit to compile it.

Quote:Originally posted by Feanor
if I want to switch back and forth from full screen, I have to re-generated the context every time.

You ought to be doing that anyway, so that users can drag the window to another display, and then go fullscreen there.

(Another way of looking at it: if you grab one fullscreen context on app launch, and I have two displays, which one are you using? How do you know which one I want?)



Dunno if this is your problem, but on my Powerbook I had to add this to my context creation:
... where display is figured out on the fly:

You can grab the Untima 9 source for working fullscreen GL context code.

Quote:Originally posted by arekkusu
You ought to be doing that anyway, so that users can drag the window to another display, and then go fullscreen there.

(Another way of looking at it: if you grab one fullscreen context on app launch, and I have two displays, which one are you using? How do you know which one I want?)

You can do the usual thing (as GameShell does) of requiring the user to pick the screen to run on at startup, and use that screen both for fullscreen and windowed modes.

Each has its own merits. If your game has few OpenGL objects (textures, display lists, &c), by all means destroy the context each time. If you have many objects, the load time switching screens will be too great anyway, so getting the user to pick a screen and stick with it isn't a bad solution.

OSC, I just created all my textures etc in another context and shared them. No delay.

The "drag" method of picking a fullscreen context is more intutive for me, but TMTOWTDI...

AFAIK, you can't share textures between window and fullscreen without specifying which screen (or at least which accelerator?) they're to run on.

*whines*

After reading many things, I'm going to have to do a major rewrite to my game. Apparently creating a controller and then a seperate OpenGLview thing is my only choice...

*mumbles something about why couldn't apple make this easy