View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0031301||FPC||Packages||public||2017-01-30 18:47||2020-07-16 10:40|
|Reporter||Chris Rorden||Assigned To|
|Summary||0031301: Include glcorearb to allow OpenGL Core support|
|Description||Last summer (issue 0029051) I suggested updating glext.pp to support OpenGL CORE implementations (e.g. MacOS). However, modifying glext has several issues:|
1.) Users have no way of telling if a function or constant is supported in the core implementation.
2.) My implementation differs from the reference C distribution, where users use gl/glext for compatibility implementations and glcorearb for core implementations.
3.) glext.pp uses "glGetString(GL_EXTENSIONS)" to check whether extensions exist, but this function is not supported by the Core spec.
Therefore, I have written a freepascal program (attached) that ports the official Khronos "glcorearb.h" to pascal (creating "glcorearb.pas", attached).
I would like to suggest we keep the same glext.pp that ships with fpc 3.0.0 (skipping patches I submitted in 0029051).
|Steps To Reproduce||I have created 3 Lazarus tutorial projects to validate and demonstrate glcorearb|
I have added the glcorearb to the Lazarus PLY/OBJ viewer Plyview:
I have also added support for glcorearb to the Lazarus project Surf Ice (edit opts.inc for CoreGL)
Finally, I added support to MRIcroGL (edit opts.inc for CoreGL)
All of these projects compile and run on Linux, MacOS and Windows.
|Additional Information||Only the attachment "glcorearb.pas" is required, the file glcorearb.h is the Khronos C header and c2p_glcorearb.pas is the tool I created to port glcorearb.h to glcorearb.pas.|
|Tags||No tags attached.|
|Fixed in Revision|
glcorearb.zip (66,868 bytes)
||Doesn't dglopengl already do something similar? Everything is a procvar there, and you can load extensions/core up to versions.|
||Hmm. I would look at that code, Marco. Interesting.|
||Using dglopengl was my original suggestion, but this option was rejected by others in 0029051. Regardless, I still think using glcorearb is cleaner than using dglopengl. For example, consider the function "glTexImage3D" which exists in both standard and core spec. Using this in the Core profile with the internal format of GL_ALPHA will cause MacOS to crash. If someone uses glcorearb to compile their code, they will be told that the constant "GL_ALPHA" does not exist in this profile, and they will need to adapt their code to use something else (e.g. for my code I went with "GL_RED"). By identifying which constants have been removed, it is much easier to port legacy openGL to modern OpenGL, as the compiler identifies missing functions and constants.|
First, I think it is pointless to have multiple differing headers in the small pascal/delphi opengl community.
I don't understand your glteximage3d example since your unit defines
GL_ALPHA = $1906;
||Not multiple, just one set of correct headers.|
This is not about correct headers, but enforcing a way of using them.
I'm not interested, since while most of my code is modern, I need to use some old calls (glscalef/gltranslatef/glbegin/end) for wglusebitmap font support.
Typo in my example regarding "GL_ALPHA", I meant "GL_LUMINANCE" - for example if you compare the Texture3D call in my legacy OpenGL volume renderer
to my core volume renderer
To be clear, I am suggesting we provide glcorearb IN ADDITION to the existing GL/GLEXT. All users like you who use GL/GLEXT can continue to do so, and your code will continue to work. However, as before your code will be limited to OpenGL 2.1 if you target MacOS.
Please note that I am suggesting the same structure Khronos suggests for the C headers: GL/GLEXT for legacy/compatibility and GLCOREARB for Core.
Marco - I can completely understand if you want to mix modern and legacy OpenGL - in that case you keep on using GL/GLEXT. However, any user that wants to target MacOS along with Windows and Linux does not have this option: they MUST choose either Legacy (limited to 2.1) or Core.
By the way, with your desire to use glscalef, gltranslatef, you may want to look at my demos: I created a unit called "gl_core_matrix" that emulates these classic calls.
Finally, with regards to glbegin/glend - I agree that the immediate mode is very convenient, and it is sad that the Core profile dropped these. However, this is the reality of what is provided to MacOS users. Also, you may want to look at my surf ice project:
the opts.inc file allows you to decide whether you want to compile for legacy (using immediate modes glbegin/glend) or core (where I provide a Core-compatible set of routines nglbegin, nglend). In my experience, while moving away from immediate mode can be a hassle, it can also provide better performance.
I have my doubts about adding yet another set of units for the benefit of compiler warnings for a limit set of constants that is different between core and legacy. Yes, theoretically it can alert a beginner but as I said I don't like fragmenting the already too small pascal opengl for it.
Myself, I nowadays use dlgopengl mostly, though the codebase was originally developed with GL/GLEXT. If only because it is very actively maintained.
As said, I afaik only use core profile, including own matrices. It is only for the windows specific wglusebitmapfont (that loads a font into calllists) that I do old skool because fine fonts are fast and always readable that way.
An older unit test of my code is here: http://forum.lazarus.freepascal.org/index.php/topic,30556.msg194484.html#msg194484 though afaik that is without the wglusebitmatfont (reintroduced later because the signed distance font scaled badly to small sizes)
The current FreePascal includes GL/GLEXT, and this does not allow MacOS users to use OpenGL versions later than 2.1 (GLSL 1.2). If we want to allow MacOS users to access this (and makers of Linux/Windows code to also target modern OpenGL) we have 3 options:
1.) Include dglOpenGL - my original suggestion (0029051)
2.) Update GLEXT to allow programs to launch a core profile (my kludge in 0029051)
3.) Include GLCOREARB (what I suggest here)
You seem to think that the benefit is only to limit compiler warnings, but this is not accurate: the current GLEXT fails to load any versions of OpenGL greater than 2.1 on OSX (as it REQUIRES functions removed from Core and uses the removed glGetString(GL_EXTENSIONS) to add functions.
My current suggest is convenient, as it has no impact on old code, is completely modular, mimics what is done with C (so users can easily port demos), and provides nice compiler warnings for removed functions.
Note that your usage case does not change - you can use either GL/GLEXT or dglOpenGL. However, including glcorearb would allow users to 'write once, compile anywhere' with modern OpenGL if they desire.
By the way, I looked at your linked code, and it does look like an elegant way to draw text in OpenGL and your shaders use modern OpenGL shaders (avoiding deprecated calls like gl_ModelViewProjectionMatrix).
I would support 3) depending on tests and examples on how to use.
My own patch to remove X dependencies was not very elegant and 3) would solve that, I hope, since it is straight Khronos, and that is the better option.
Note that for my initial purpose (Raspberry Pi support) the issue disappeared, since later Pi's support OpenGL besides OpenGles.
I agree. I would very much like to see glcorearb included.
I include Lazarus examples of OpenGL Core that compile for Linux, Windows and MacOS. OpenGL Core requires shaders, so it is necessarily harder to create a first project than classic OpenGL (which provides fixed function pipelines). However, this is true of all advanced APIs (Metal, Vulkan, etc). The demos start very simply and demonstrate advanced features:
I would be happy for these to be included with Lazarus. Please tell me if there is any way I can expedite this review.
Then maybe just include everything dglopengl, glcorearb etc.
I had hoped that in time the package system would be operational, but that is pretty glacial
|2017-01-30 18:47||Chris Rorden||New Issue|
|2017-01-30 18:47||Chris Rorden||File Added: glcorearb.zip|
|2017-01-30 22:20||Marco van de Voort||Note Added: 0097827|
|2017-01-31 12:17||Thaddy de Koning||Note Added: 0097834|
|2017-01-31 14:33||Chris Rorden||Note Added: 0097837|
|2017-01-31 16:05||Marco van de Voort||Relationship added||related to 0029051|
|2017-01-31 16:23||Marco van de Voort||Note Added: 0097839|
|2017-01-31 17:17||Thaddy de Koning||Note Added: 0097843|
|2017-01-31 17:55||Marco van de Voort||Note Added: 0097844|
|2017-01-31 21:46||Chris Rorden||Note Added: 0097853|
|2017-01-31 21:52||Chris Rorden||Note Edited: 0097853||View Revisions|
|2017-02-01 09:41||Marco van de Voort||Note Added: 0097859|
|2017-02-01 11:30||Marco van de Voort||Note Edited: 0097859||View Revisions|
|2017-02-01 14:55||Chris Rorden||Note Added: 0097876|
|2020-05-01 09:21||Thaddy de Koning||Note Added: 0122572|
|2020-05-01 09:32||Thaddy de Koning||Note Edited: 0122572||View Revisions|
|2020-07-15 22:26||Chris Rorden||Note Added: 0124065|
|2020-07-16 10:40||Marco van de Voort||Note Added: 0124080|