So in the driver settings under Anti-Aliasing we all know there are usually 6 settings:
Application Controlled, Off, 2x, 4x, 8x and 16x.
My question is, how (as an application) do you switch between the other 5 settings? Calling glEnable(GL_MULTISAMPLE) is a binary switch (off and what? 2x? 4x? etc?).
If I set my driver to Application Controlled how can I code my application so I can swap between the various settings? Or is that even possible?
In your wglChoosePixelFormatARB() call, add this to your attribute list:
WGL_SAMPLE_BUFFERS_ARB, 1,
WGL_SAMPLES_ARB, <your sample count here>,
Right but that only happens on window creation… which is not really what I wanted 
Thanks though.
I just found this post…
http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=012447#000000
Which goes into it in more detail.
True, and it is only possible to set it on window creation. A workaround would be drawing to a multisampled FBO, but this still isn’t supported on ATI.
You cannot switch the antialiasing mode at run-time, without recreating the window. That’s because your framebuffer needs to be setup accordingly.
But, it’s the same issue as with window resolution, etc. Every time you want to change such a basic option, you need to recreate your entire window.
This is, why many games actually don’t let you change this at “run time”, but only in a dialog at startup, before the actual window gets created.
Jan.
Umh, but theres a difference. Changing the AA mode requires one to select a different pixel format. This means, the entire context will have to be recreated. While when just recreating the window (with pixel format unchanged), the context can remain. I ope they will introduce another model for gl3
Originally posted by Jan:
But, it’s the same issue as with window resolution, etc. Every time you want to change such a basic option, you need to recreate your entire window.
You don’t need to recreate the window if you changed the resolution. You just need to resize your window and if you changed from windowed mode to fullscreen or vice versa you need to show/hide window decorations like a title bar. It’s some WinAPI magic which minimalist libraries like SDL cannot provide you (one reason not to use them). You can do the same in Xlib as well.
Changing the AA mode requires one to select a different pixel format. This means, the entire context will have to be recreated.
I seriously hope that GL 3.0 is sufficiently expressive that it is possible to create a “front-buffer-only” context and allowing the application to do all the antialiasing in the back buffer, then blit to the front-buffer. This is possible in 2.1 with the multisample extensions, but they’re not widely supported (ie: ATi didn’t bother).
While when just recreating the window (with pixel format unchanged), the context can remain.
Um, no.
The GL rendering context is bound to a window’s device context. When that window dies, so too does its DC. Just because you didn’t properly shut down the GL rendering context doesn’t mean that it didn’t go away.
The GL rendering context is bound to a window’s device context. When that window dies, so too does its DC. Just because you didn’t properly shut down the GL rendering context doesn’t mean that it didn’t go away.
Even with wglShareLists tricks ?
I’ve often wondered why you can only set a windows pixel format once - because it obviously has a pixel format when it’s initially created (single buffered, no opengl support), and it then allows you to change it to something else, but not again after that.
Korval, that is not entirely true. You can bind an OpenGL context to any DC, as long as the pixel format equals to one used to create the context. So basically,
wglMakeCurrent(rc, 0)
DeleteWindow()
new_dc = CreateNewWindow()
wglMakeCurrent(rc, new_dc)
Actually, my dream context creation API won’t bind rendering context to a window at all. Really, modern OSs (MacOS, Vista, all that fancy 3d X servers) tend to do some window composition - so it ends being rendered to an offscreen buffer anyway. It would be nice if we could blit a renderbuffer to a window. Something like
dc_renderbuffer = wglglxCreateRenderbufferForDC(dc, rb_template);
FramebufferAttachement(fbo, COLOR0, dc_renderbuffer);
draw...
wglBlitToDC(dc_renderbuffer);
Something like that should be pretty easy to implement for driver writers, and IMHO, the performance should match the one we have now. We would get a consistent and clear API, as context creation could be moved to the OpenGL core.
P.S. knackered, I am not sure if I remember this correctly, as it was a long time ago, but I thought that running GetPixelFormat on a newly created window returns zero…
BTW, are pixel formats actually used by Windows for something other than creating OpenGL contexts?
Something like that should be pretty easy to implement for driver writers, and IMHO, the performance should match the one we have now. We would get a consistent and clear API, as context creation could be moved to the OpenGL core.
Well, according to the last pipeline newsletter, they hadn’t entirely decided how rendering to a window worked exactly. If you were to render directly to a window’s framebuffer, what was suggested by someone from the ARB is that you would be able to fetch an FBO using the window system-dependent API that you could bind (but not alter). But that is (was?) somewhat up in the air as of a few months ago. I imagine it’s been sorted out by now and we’ll find out how it works in the next newsletter (which hopefully will just be a link to the GL 3.0 spec. I could live with that).
Really, as long as I can effect the construction of that FBO sufficiently (as I suggested, asking for a single color-only buffer, so that I do all my rendering to images I allocate), I don’t mind.
AFAIK, pixel formats are GL-only thing. And an awkward one 