Home/ Questions/Q 844723
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T06:19:55+00:00

I’m working on a C++ cross-platform OpenGL application (Windows, Linux and MacOS) and I

  • 0

I’m working on a C++ cross-platform OpenGL application (Windows, Linux and MacOS) and I am wondering if some of you could share some advices on porting a large application to OpenGL 3. The reason I am looking into OpenGL 3 is because I think we could benefit a lot from using the new “Sync objects”. Nvidia has supported such an extension since the Geforce 256 days (gl_nv_fences) but there seems to be no equivalent functionality on ATI hardware before OpenGL 3.0+…

Our code makes quite heavy use of glut/freeglut, glu functions, OpenGL 2 extensions and CUDA (on supported hardware). The problem I am now facing is that “gl3.h” and “gl.h” are mutually incompatible (as stated in gl3.h). Do you guys know if there is a GL3 glut equivalent ? Also, looking at the CUDA-toolkit header files, it seems that GL-CUDA interoperability is only available when using older versions of OpenGL… (cuda_gl_interop.h includes gl.h…). Am I missing something ?

Thanks a lot for your help.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The last update to glut was version 3.7, roughly 10 years ago. Taking that into account, I doubt that it’ll ever support OpenGL 3.x (or 4.x).

    The people working on OpenGlut seem to be considering the possibility of OpenGL 3.x support, but haven’t done anything with it yet.

    FLTK has a (partial) glut simulation, but it’s partial enough that a program that “makes heavy use of glut” may not work with it in the first place. Since FLTK is in active development, I’d guess it’ll eventually support OpenGL 3.x (or 4.x), but I don’t believe it’s provided yet, and it may be open to question how soon it will be either.

    Edit: As far as CUDA goes, the obvious (though certainly non-trivial) answer would be to use OpenCL instead. This is considerably more compatible both with hardware (e.g., with ATI/AMD boards) and with newer versions of OpenGL.

    That leaves glu. Frankly, I don’t think there is a clear or obvious answer to this. OpenGL is moving away from supporting things like glu, and instead dropping support for even more of the vaguely glu-like functionality that used to be part of the core OpenGL spec (e.g., all the matrix manipulation primitives). Personally, I think this is a mistake, but whether it’s good or bad, it’s how things are. Unfortunately, glu is a bit like glut — the last update to the spec was in 1998, and corresponds to OpenGL 1.2. That doesn’t make an update seem at all likely. Unfortunately, I don’t know of any really direct replacements for it either. There are clearly other graphics libraries that provide (at least some) similar capabilities, but all of them I can think of would require substantial rewriting.

    • 0