Do I clamp my frame rate to vertical retrace with opengl or do I have to do it with os calls? (I am using sdl and compiling for win32 and linux)
opengl has nothing to do with the retrace, so you’ll need to talk to the o/s about that.
cheers,
John
Actually, thats not correct. wglSwapIntervalEXT can be used to do this. It takes a single integer parameter, which is the number of vsynch to wait. 0 will make it flip the buffers instantly and 1 will wait for the next vertical retrace. Values higher than 1 dont seem particularly useful to me (can anyone give me a scenario where they would be handy), and I’m not sure that all cards would deal with greater than 1 (it seems reasonable that some cards might only understand values of 0 and 1). Its also worth noting that some drivers provide options to override the vsynch settings, and there isnt really anything you can do about that.
Anyway, wglSwapIntervalEXT is an extension, so you need to test for it the extension string (I think its “WGL_EXT_swap_control”) and then you will need to call wglGetProcAddress.
Actually, this only works in windows. I dont really have any experience with non-windows platforms, so Im not sure how you would go about it elsewhere.
[This message has been edited by LordKronos (edited 01-29-2001).]
yer, exactly. “this works in windows” with the dicky windows gl stuff. wgl stuff isn’t OPENGL stuff, its windows extentions for use with opengl in the same way the glx is x-windows extentions to opengl, and glut is the ulil toolkit extensions to opengl, without ever actually BEING opengl. So, what i said is still true: opengl is solely concerned with describing graphical primitivies and operations on those primitivies [1] and not with how the graphics device ends up talking to the monitor? wgl is NOT part of opengl, but rather extensions to the api that someone thing is useful (in the same way that glut is a useful api associated with opengl, but still NOT part of opengl).
Another way of saying this is: opengl is a platform independent graphics api. wgl is windows specific, ergo, it is not platform indepdendent and THEREFORE not part of a platform INdependent api.
cheers,
John
references:
[1] The OpenGL Graphics Interface
M. Segal, K. Akeley
SGI Computer Systems,
http://trant.sgi.com/opengl/docs/white_papers/oglGraphSys/opengl.html
“[…] OpenGL is a software interface to graphics hardware. The interface consists of a set of several hundred procedures and functions that allow a programmer to specify the objects and operations involved in producing high-quality graphical images, specifically color images of three-dimensional objects”
(ie. to specify how objects are described and operations to perform on them, not how the frame buffer is sent to the display)
[This message has been edited by john (edited 01-29-2001).]
I disagree. It is part of the Windows extensions to opengl, therefore it is part of opengl. Is it part of the base specification…no. But just because it is part of an extension does not make it “not OpenGL”.
If someone asked you how they could do vertex weighting, would you say “nope sorry, you cant do vertex weighting in OpenGL. There is that EXT_vertex_weighting extension, but thats not part of openGL, so you will need to talk to the graphics card about that”. I certainly wouldnt. I would say “Yes, you can do it, but you need to use the EXT_vertex_weighting extension, so it wont be supported on all graphics cards”.
you are talking about different things, tho. the vertex weighting extention is part of the API to describe graphics primitives and operations to be performed on them, which is the scope of OpenGL (and I cited a whitepaper to this effect).
opengl is ONLY concerned with drawing primitivies. Yes, a core part of openGL must be supported for a given API to be called opengl, but there are extensions which are not supported, and arguably they are part of opengl.
But: waiting for retrace has NOTHING to do with 1) describing graphcis primitives, nor 2) operations to perform ON those primitives, ergo, it has ntohing to do with opengl because opengl is ONLY concerned (and, again, i cite the white papers on opengl) with doing these two things.
retrace has nothing to do with primitives, but EVERYTHING to do with how a frame buffer is sent to the monitor. Yer, its graphcis, but… so what? some monitors let you change their settings through s/w. Since this is also graphics related, does this mean it is automagically included as “part of opengl”? obviously not, so being graphics related alone is NOT a sufficient reason to be labeled as part of OpenGL.
glx, agl, wgl, glut are all api’s used WITH opengl, but not PART of opengl.
If i do this, am i adding to OpenGL:
void fglFreakedOpenGLExtentionMalacky(void)
/* ^^ has the gl prefix. WHOO HOO */
{
playSoundOnSoundCard(“silly.wav”);
}
? no.
what about higher level apis, like crystalspace that make use of opengl, but are (themselves) an API. is crystalspace a magical extension to opengl? what about optimizer? volumizer? are they PART of the opengl 1.2 specifications, or api’s that are ised WITH opengl?
cheers,
John
[This message has been edited by john (edited 01-30-2001).]
dont try and stick with that “describe graphics primitives and operations to be performed on them” line. Ideally, and for the most part, yes it is true, but it is not a hard and fast rule. You say “opengl is ONLY concerned with drawing primitivies”, yet selection and feedback dont actually draw a single pixel to the screen, but they are part of OpenGL. Selection and feedback are actually high level features that dont really belong in a low level graphics API (they are more along the lines of scene management techniques). Yet they are there, and they are part of opengl.
Also, what about double buffering. Would you say that isnt a part of OpenGL, but rather an operating system function? It doesnt “describe graphics primitives and operations to be performed on them”. It deals with when things are displayed to the user, just like the swap interval.
glx, wgl, and I assume agl (I’ve never heard of it) are indeed openGL extensions. They are part of openGL, just not the core. glut is something differt, so dont try to put that in the same group. Glut is a utility library that sits on top of the opengl runtime libraries. It is in no way integrated into openGL. There are no glut extensions to openGL (as far as I know). Glut just provides simpler ways for you to call openGL functions, to initialize, and to create high order surfaces & objects.
And you can put all the freakin’ fgl prefixes on your functions that you want, thats not what Im talking about. Im talking about EXTENSIONS, not functions…maybe you dont seem to see the distinction.
No need to get into an argument about this, guys. 
Check the original post again. mwanderson is compiling for win32 and linux. I think that you CAN agree that wgl* functions are OS specific. It doesn’t matter if you see them as actually being a part of OpenGL, or OS calls.
Just as a note, wgl* functions are defined in wingdi.h, so I would tend to classify them more as OS functions, but I can see how they could be considered OpenGL functions as well. (How’s that for trying to stay neutral?)
This is a very interesting discussion, where does openGL end and the OS (or openGL wrappers) begin? I run into questions like this all the time when I am trying to build a new library or interface, ie where do I draw the line. I think the extension interface is good solution to that problem. I got the swap extension to work. I like the linux (or mesa) extension interface, it is alot easier to deal with. So far in linux I haven’t had to getProcAddress at all, all the extensions I use are already enumerated and link at run time Linux Rules!
PS if anyone is interested here is a link to the demo that lead to this question,ftp://64.69.81.60/pub/Gldemo.zip