bug in OpenGL setup for NSOpenGL subclass (I think) - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Graphics & Audio Programming (/forum-9.html)
+--- Thread: bug in OpenGL setup for NSOpenGL subclass (I think) (/thread-3174.html)
bug in OpenGL setup for NSOpenGL subclass (I think) - backslash - Jul 18, 2007 11:31 AM
or "I've managed to write a Universal Binary that doesn't work on Intel!"
Having just bought a shiny new MacBook, I decided to try out my pre-pre-alpha game (there's actually no gameplay whatsoever at the moment) on it. Amazingly, it runs, everything initialises and all behaviour is working as it does on my G4 Mac Mini, except that my graphics don't draw unless I cover the window with another app or push it off the side of the screen.
I've subclassed NSOpenGLView and used a Custom View thingy in Interface Builder to plant it in a window. An NSTimer fires off my game loop every 20ms, and the game loop tells the NSOpenGLView subclass to setNeedsDisplay:YES.
I've verified that drawRect is getting called, and there are no OpenGL errors. I've spent many hours scouring Google and trying various plausible solutions, but with no success. I thought it might be something to do with my previous strategy of putting the NSOpenGLView into an NSPanel and setting that to be the content of the NSWindow, but changing that has made no difference. I stripped the project to a version with only the GameController and TNeb_OpenGLView classes and no third party libraries, and the same thing happened, so I think it must be something to do with the way I'm setting up my OpenGL context or the view, but I'm a bit stumped as to what it might be. So I thought maybe a fresh pair of eyes (attached to someone who actually knows what they're doing!) might be able to point the obvious mistake for me.
Here's the relevant bits of TNeb_OpenGLView.m
bug in OpenGL setup for NSOpenGL subclass (I think) - arekkusu - Jul 18, 2007 12:29 PM
[[self openGLContext] flushBuffer];
glFlush only flushes the command queue, it does not swap back buffer to the display. Since you have a double buffered context, all of your rendering stays in the back buffer (until you drag a another window on top of yours, then the compositor picks up partially drawn bits.)
bug in OpenGL setup for NSOpenGL subclass (I think) - backslash - Jul 18, 2007 01:10 PM
Thank you - that's worked great... on the MacBook. The Mac Mini started giving me a window full of garbage after that change. At that point I remember not being able to figure out how to swap the buffers a while back and putting in the line glDrawBuffer(GL_FRONT) as a temporary hack, which I forgot about. I changed it to glDrawBuffer(GL_BACK) and now all is happy on both machines. Does the GMA950 refuse to draw to the front buffer, or something.
I've also just discovered that my Mac Mini has updated to 10.4.10 when I wasn't paying attention, but I doubt that is it.
Anyway, buffering never even occurred to me. You are indeed a genius.