Fractalforums

Would probably require restart on change, none the less, will look at your fork and do some testing after work today.

ok did some testing...

desired GL version selected in preferences and saved, restart FragM

construct a QGLFormat object (as mentioned in FragM source in an earlier post)
before creating the engine using the QGLFormat object, output to console the selected GL version

> "GL vers 1.1 requested."

after creating the engine, output to console the actual GL version used in the engine...

    qDebug() << QString("GL vers %1.%2 created.").arg(engine->context()->format().majorVersion()).arg(engine->context()->format().minorVersion());
> "GL vers 4.5 created."

One of the implied advantages of using v3+ core profile is vertex arrays and vertex buffer objects, but FragM only draws 1 triangle with 3 vertices so I don't think it's an advantage for the current setup.

Quote from the link you provided "This is known to work under Linux but Windows and macOS have some issues inside of Qt for creating Core Profile contexts."

When we set the version and profile in the frag code it then strictly enforces the version in the compiler parser and throws errors for deprecated commands and syntax

I would still like to recreate FragM using modern stuff like QGLSurface and friends...

edit: ..while retaining legacy functionality, after a little more hacking added profile and version to preferences dialog, crashes on core profile so I t must be setting profile properly, Qt's default is compatibility so all versions valid? core fails for the reasons you mention glBegin() etc. will have a look at your fork soon.

I have created a branch on github named runtime-profile-version that has the changes from that diff I sent you.

from the command line...
  -g, --glversion <glversion>  GL version to use for main display.
                                eg: 4.1
  -p, --glprofile <glprofile>  GL Profile to use for main display.
                               Possible values are 'compat', 'core', 'none'

settings can be found in menu Edit->Preferences

suggest running from console for debug output.

not sure if this is 'proper' but it seems to work. In Qt all lower versions of GL are subsets of the highest version available, so, if a binary is compiled on a machine that supports 4.6 compat it should be able to run on a machine that supports 3.3 core...

Ok I'm not sure what the desired behaviour is, but
$ ./Fragmentarium-2.0.0 -g 3.0 -p none
"GL vers 3.0 requested."
"GL prof None requested."
"GL vers 4.5 used."
"GL prof Core used."is not what I expected - What should I specifiy on the command line if I don't want a 4.5 core profile because the fragm engine and shaders don't support it yet and I want to make some fractals instead of hacking on the engine to make it work with 4.5 core?

the desired behavior of the runtime-profile-version branch is entirely experimental to see if FragM can manage profile and version selection at runtime.

quotes from Qt docs...

qthelp://org.qt-project.qtgui.561/qtgui/qopenglcontext.html#format

The requested and the actual format may differ. Requesting a given OpenGL version does not mean the resulting context will target exactly the requested version. It is only guaranteed that the version/profile/options combination for the created context is compatible with the request, as long as the driver is able to provide such a context.

For example, requesting an OpenGL version 3.x core profile context may result in an OpenGL 4.x core profile context. Similarly, a request for OpenGL 2.1 may result in an OpenGL 3.0 context with deprecated functions enabled. Finally, depending on the driver, unsupported versions may result in either a context creation failure or in a context for the highest supported version.

qthelp://org.qt-project.qtgui.561/qtgui/qopenglcontext.html#versionFunctions-1

It is possible to request a functions object for a different version and profile than that for which the context was created. To do this either use the template version of this function specifying the desired functions object type as the template parameter or by passing in a QOpenGLVersionProfile object as an argument to the non-template function.

Note that requests for function objects of other versions or profiles can fail and in doing so will return a null pointer. Situations in which creation of the functions object can fail are if the request cannot be satisfied due to asking for functions that are not in the version or profile of this context. For example:

Code: [Select]

QOpenGLFunctions_3_3_Core* funcs = 0;
  funcs = context->versionFunctions<QOpenGLFunctions_3_3_Core>();
  if (!funcs) {
      qWarning() << "Could not obtain required OpenGL context version";
      exit(1);
  }Requesting a 3.3 core profile functions object would succeed.
Requesting a 3.3 compatibility profile functions object would fail. We would fail to resolve the deprecated functions.
Requesting a 4.3 core profile functions object would fail. We would fail to resolve the new core functions introduced in versions 4.0-4.3.
Requesting a 3.1 functions object would succeed. There is nothing in 3.1 that is not also in 3.3 core.

The way Qt implements GL is the reason I ended up with 2 versions of FragM, one for < GL4.1 and one for > GL4.0

I think profile and version selection at runtime will only be good for a limited range and definitely won't cover all possibilities.

edit: this leads me to believe that in order to cover all possibilities there would have to be 3 versions of FragM, Legacy, GLES and Modern (4+) eventually dropping the Legacy version.