GLUT apple menu close application

[Rasterman]

Is there a way to disable or capture the Quit Application command when issued by the command bar? The problem I am having is my game isn't saving settings when its closed via this method, glutMainLoop isn't returning, maybe I can capture this by hooking exit(int)?

[OneSadCookie]

glutMainLoop never returns, as the docs say.

No, you can't alter the fixtures that GLUT gives you. If you want more control, you can write your GUI yourself in Cocoa.

You can use "atexit" to have something run when your app exits.

[Tobs_]

Can't you just do something like

Begin/Init code
glutMainLoop
Save Settings
end

Tobs

[Fenris]

No, because glutMainLoop doesn't return, it calls exit(1) instead. :)

[wyrmmage]

you could always have another program load your program as a child and then you could have code after the child program exited; this probably isn't a great way to go, though...you'd be better off taking OSC's route.
-wyrmmage

[Duane]

...because glut is a load of flying !$%@#.
Personally, I'd just save the settings as they are set. Of course, you could always use atexit, as osc suggested, to do what you were doing before.

[AnotherJake]

...because glut is a load of flying !$%@#.

... since when? :rolleyes:

[OneSadCookie]

GLUT's very good at what it was designed for -- being a very quick and easy way to get an OpenGL program up and running.

For anything else (like, say, shipping a game), it's precisely what Nayr says it is ;)

[AnotherJake]

GLUT is what GLUT is. It works perfectly for what it was designed for. Calling it a superlatively bad thing is not what it was designed for.;)

[Nevada]

Personally, I think setting up your own custom OpenGL view is a learning experience. (BTW, if your using Cocoa, do the extra work and derive from NSView, not NSOpenGLView. You won't get true double buffering the other way). Anyway, ADC has some pretty good sample code for this sort of thing...

[AnotherJake]

Personally, I think setting up your own custom OpenGL view is a learning experience. (BTW, if your using Cocoa, do the extra work and derive from NSView, not NSOpenGLView. You won't get true double buffering the other way).
Say wuh? What is `true' double buffering? NSOpenGLView has worked perfectly fine for me for years.

[OneSadCookie]

I think what Nevada is trying to say is that if you drag an NSOpenGLView in IB2, you can't get double buffering. However, that's not to say that NSOpenGLView is useless; dragging a custom view, making it an instance of a custom subclass of NSOpenGLView, works just fine.

Personally, these days, I prefer to avoid NSOpenGLView, however. I find that I don't want many of the things it does for me, and do want a bunch of stuff which is just as hard to add to NSOpenGLView as NSView, so there's no benefit.

[AnotherJake]

I think what Nevada is trying to say is that if you drag an NSOpenGLView in IB2, you can't get double buffering. However, that's not to say that NSOpenGLView is useless; dragging a custom view, making it an instance of a custom subclass of NSOpenGLView, works just fine.
Yeah, that's what I've always done. I haven't had any problems with it at all, and have not yet found a need to subclass directly from NSView.

The IB palette glView is junk. I'm not sure why they have it in there.

[Nevada]

Eh, I just said screw it and went with NSView. I think in the long run I may need something that NSOpenGLView doesn't support. I just remember constantly trying to set up a pixel format for it, but consistently getting jitters.

[AnotherJake]

Eh, I just said screw it and went with NSView. I think in the long run I may need something that NSOpenGLView doesn't support. I just remember constantly trying to set up a pixel format for it, but consistently getting jitters.
What do you mean by `jitters'? What were you using for your pixel format? Were you mistakenly trying to use NSOpenGLPFAStereo or something? If NSView is really better than NSOpenGLView performance-wise then that is *really* important! I am a bit surprised here that NSOpenGLView sounds like such a bad subclass of NSView to begin with. I am skeptical but I'll stop using it if there is something wrong with it. I have seen absolutely nothing wrong with it for years, and I have used it a LOT, so I am very curious about this.

[OneSadCookie]

It's nothing fancy, just a bit of a convenience. Certainly, no performance benefits to not using it, nor any pixel format attributes you can't get with it.

[Nevada]

What do you mean by `jitters'? What were you using for your pixel format? Were you mistakenly trying to use NSOpenGLPFAStereo or something? If NSView is really better than NSOpenGLView performance-wise then that is *really* important! I am a bit surprised here that NSOpenGLView sounds like such a bad subclass of NSView to begin with. I am skeptical but I'll stop using it if there is something wrong with it. I have seen absolutely nothing wrong with it for years, and I have used it a LOT, so I am very curious about this.

There were (brief) ghost images, the kind that are a sure sign of the lack of double buffering. I had very basic PFA's (nothing like Stereo) including NSOpenGLPFADoubleBuffer. My guess is that the pixel format I was coding was being 'overwritten' by the NIB file upon load. Maybe I set them in the incorrect spot, or maybe I'm just clumsy, I can't remember. Either way, it was certainly a double buffering problem (not vsync, I took care of that). If you've been using it without problems, there's probably no reason to tamper with it unless you hit some problems. Re-coding it may cause more problems than it will fix. I can't imagine why one would have better performance than the other... The key here is flexibility.

[AnotherJake]

...Re-coding it may cause more problems than it will fix...

If I could get any solid confirmation that there is good reason not to use NSOpenGLView then I would not use it -- re-coding is not an issue for me at all (especially the view, which is very simple). It would be helpful if you could reproduce the problem. Otherwise I would maintain that NSOpenGLView should be considered rock-solid, and not to be avoided.

[AnotherJake]

I should add that I am in no way opposed to subclassing NSView directly. There really isn't much extra that comes with NSOpenGLView when it comes down to actual usage. I wind up piling a lot of other stuff on top of it anyway. I guess as it stands from this little discussion, I don't see any particular reason to go NSOpenGLView or NSView -- either way gets to the same result as far as I can see. And I don't see any more or less extra flexibility in using either... [shrugs]

[Nevada]

I probably set the pixel format in the wrong place. I believe I did it in the initWithFrame: method. Where do you set your pixel format attributes?

[AnotherJake]

In initWithFrame. Here's a typical example (contextInit just gets called at the top of initWithFrame to help separate the code out a bit -- nothing tricky):
- (void)contextInit:(NSRect)frameRect
{
NSOpenGLPixelFormat *fullScreenPixelFormat, *windowedPixelFormat;
NSOpenGLPixelFormatAttribute attribs[] = {
NSOpenGLPFAWindow,
NSOpenGLPFAColorSize, (NSOpenGLPixelFormatAttribute)32,
NSOpenGLPFADepthSize, (NSOpenGLPixelFormatAttribute)32,
NSOpenGLPFAStencilSize, (NSOpenGLPixelFormatAttribute)8,
NSOpenGLPFAAccumSize, (NSOpenGLPixelFormatAttribute)8,
NSOpenGLPFAAccelerated,
NSOpenGLPFADoubleBuffer,
NSOpenGLPFASingleRenderer,
NSOpenGLPFANoRecovery,
NSOpenGLPFAScreenMask,
CGDisplayIDToOpenGLDisplayMask(kCGDirectMainDispla y),
(NSOpenGLPixelFormatAttribute)0 };

windowedPixelFormat = [[NSOpenGLPixelFormat alloc] initWithAttributes:attribs];
if (windowedPixelFormat == nil)
[self contextCreationFailure:@"Unable to create windowed pixel format."];
attribs[0] = NSOpenGLPFAFullScreen;
fullScreenPixelFormat = [[NSOpenGLPixelFormat alloc] initWithAttributes:attribs];
if (fullScreenPixelFormat == nil)
[self contextCreationFailure:@"Unable to create full screen pixel format."];
self = [super initWithFrame:frameRect pixelFormat:windowedPixelFormat];
if (self == nil)
[self contextCreationFailure:@"Unable to create a windowed OpenGL context."];
currentContext = [self openGLContext];
fullScreenGLContext = [[NSOpenGLContext alloc] initWithFormat:fullScreenPixelFormat
shareContext:[self openGLContext]];
if (fullScreenGLContext == nil)
[self contextCreationFailure:@"Unable to create a full screen OpenGL context."];
[windowedPixelFormat release];
[fullScreenPixelFormat release];
}

[Nevada]

I scrapped the old code a long time ago, but there's a chance I might have left out the

self = [super initWithFrame:frameRect pixelFormat:windowedPixelFormat];

part. I can't think of any other reason why yours would work and mine wouldn't. Oh well. I'm still happy with my NSView.

[arekkusu]

The IB palette glView is junk. I'm not sure why they have it in there.

So it makes the next version look better, of course.


If I could get any solid confirmation that there is good reason not to use NSOpenGLView then I would not use it

NSOpenGLView is fine, you just need to set up the pixel format manually if you want to do anything useful.

Subclassing NSView from scratch is also OK, and a useful learning experience. Just be wary of threading issues.

[AnotherJake]

Thanks for the sanity check and the threading heads-up arekkusu. Always appreciated. :)

[Rasterman]

Hello again guys, thanks for the suggestions, I am using GLUT for a shipping game and its working quite nicely, I simply open a single buffered window and blit to it using glDrawPixels, at 1024x768 on a GMA 950 I am getting 50+ fps (including all my game logic) which is more than acceptable. I will probably try a glTexSubImage method next go around, but I don't see why that would improve anything since the same amount of data is still being transfered over the bus, which is the slow part.

[AnotherJake]

I'm surprised you're getting that kind of performance out of glDrawPixels. I'm not sure I would count on it being that solid across different machines though. The gma950 uses shared system memory for VRAM so there there is a possibility it's already there and doesn't require a transfer, but I do not know specific implementation details. For comparison, I do know that I don't get any different speed using VBOs on the gma950, so I *suspect* that there is no movement of memory, but again I have no idea. Other machines will have separate VRAM on-card and (for sure) will require a transfer to get that data there. I don't know the details with glDrawPixels, but I know for a fact you can get an automatic DMA transfer boost if you use glTexSubImage2D.

[OneSadCookie]

DrawPixels is the slow path, that's true, though on a GMA 950 if the source and destination pixel formats are the same, it might be little less efficient than a memcpy.

On a discrete graphics card, the data has to be transfered across the PCIe bus, and your application will be blocked whilst this happens unless you're using a PBO, so it'll be slow.

VBOs won't show any performance increase on the GMA 950 unless you turn on the MP engine, in which case they are a major performance improvement.

[AnotherJake]

VBOs won't show any performance increase on the GMA 950 unless you turn on the MP engine, in which case they are a major performance improvement.
Not that I've seen. MP engine does nothing for VBO performance on my Mini. I made extra double sure both MP and VBOs were enabled, and... nada, zero, zilch, zippo performance increase.

That said, most of the application is just drawing, with no other processor intensive stuff like physics or collision, etc. Perhaps then one might see a boost.

[OneSadCookie]

http://onesadcookie.com/svn/repos/Kiloplane is where I see the difference. From memory, 1.5x faster..

[AnotherJake]

http://onesadcookie.com/svn/repos/Kiloplane is where I see the difference. From memory, 1.5x faster..
I definitely would like to investigate that and see if I can track down if I'm doing something wrong then. Is there any way to simply download that entire directory in one click? I am ignorant of svn.:(

[OneSadCookie]

svn checkout http://onesadcookie.com/svn/repos/Kiloplane

If you don't have subversion already, google "martin ott subversion" for a nice installer package.

[AnotherJake]

Thanks, I'll have to check that out soon and see what differences I can find.