0

Let's say I want to have an OpenGL program that runs on a platform that supports the latest OpenGL version (4.6), but also on a platform that supports a very low OpenGL version (1.5, which does not have shaders).

To create such a program, I would need at least two code paths - one that uses functions from the OpenGL 4.6, and one that uses functions from the 1.5.

What I would like to end up with is one program (one binary), which based on the system requirements ends up using the first or the second code path. By code paths, I actually mean different classes that would do the rendering using a certain set of OpenGL functions, so something like this:

// Rendering interface.
class Renderer{
...
  void init(){
    // Load OpenGL functions
    glewInit();
  }
  virtual void renderSphere() = 0;
...
};

// Rendering implementation that uses opengl 4.6
class RendererProgrammablePipeline: Renderer{
...
void renderSphere(){ /* use shaders to render a sphere */ }
...
}; 

// Rendering implementation that uses opengl 1.5
class RendererFixedFunctionPipeline: Renderer{
...
void renderSphere(){ /* use display lists to render a sphere */ }
...
};

Then during runtime, after an OpenGL context is created, I would ask what's the current OpenGL version and pick the Renderer implementation.

My question is, I am missing something (big) here with the approach described? According to this question, it seems that loading OpenGL functions at runtime might not be as simple as calling glewInit(), but it's also posted 10 years ago.

Thanks in advance for any comments and suggestions.

MarsaPalas
  • 375
  • 1
  • 6
  • 19
  • `glewInit` is enough for loading GL xtentions... In that link is just pointed out that the result is runtime only not compile time so preprocessor macros can not be used to distinguish between versions to run GL version specific code easily .... instead it must be done in runtime either by some `case` or `if`/`else` statements or by using function pointers... and also GLEW is not small stuff it contains a lot of pointers, and macros that is probably some times more code that the font lib itself hence the overkill ... – Spektre Jun 12 '22 at 05:32
  • Also beware my experience with `display lists` is that their never boost performance its usually the other way around ... They might be faster 20-30 years ago but certainly not with current HW. Another note you will have most likely need gfx vendor specific shaders and probably also CPU side code because the shader behavior is not the same ... and also beware many things does not work properly on Intel (for those I usually use fixed function) – Spektre Jun 12 '22 at 05:36
  • No, you're not missing anything. This is pretty much how it's done. Beware that creating a context should fail if you ask for an unsupported version, so you'd have to try again with a different version. – user253751 Jun 13 '22 at 10:28

0 Answers0