View Issue Details

IDProjectCategoryView StatusLast Update
0031301FPCPackagespublic2020-07-16 10:40
ReporterChris Rorden Assigned To 
Status newResolutionopen 
PlatformMacBook RetinaOSDarwin 
Product Version3.0.0 
Summary0031301: Include glcorearb to allow OpenGL Core support
DescriptionLast 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 ReproduceI 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 for CoreGL)
Finally, I added support to MRIcroGL (edit for CoreGL)

All of these projects compile and run on Linux, MacOS and Windows.

Additional InformationOnly 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.
TagsNo tags attached.
Fixed in Revision
Attached Files


related to 0029051 closedSven Barth gl.pp is very out of date 


Chris Rorden

2017-01-30 18:47

reporter (66,868 bytes)

Marco van de Voort

2017-01-30 22:20

manager   ~0097827

Doesn't dglopengl already do something similar? Everything is a procvar there, and you can load extensions/core up to versions.

Thaddy de Koning

2017-01-31 12:17

reporter   ~0097834

Hmm. I would look at that code, Marco. Interesting.

Chris Rorden

2017-01-31 14:33

reporter   ~0097837

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.

Marco van de Voort

2017-01-31 16:23

manager   ~0097839

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;

Thaddy de Koning

2017-01-31 17:17

reporter   ~0097843

Not multiple, just one set of correct headers.

Marco van de Voort

2017-01-31 17:55

manager   ~0097844

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.

Chris Rorden

2017-01-31 21:46

reporter   ~0097853

Last edited: 2017-01-31 21:52

View 2 revisions

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 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.

Marco van de Voort

2017-02-01 09:41

manager   ~0097859

Last edited: 2017-02-01 11:30

View 2 revisions

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:,30556.msg194484.html#msg194484 though afaik that is without the wglusebitmatfont (reintroduced later because the signed distance font scaled badly to small sizes)

Chris Rorden

2017-02-01 14:55

reporter   ~0097876

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).

Thaddy de Koning

2020-05-01 09:21

reporter   ~0122572

Last edited: 2020-05-01 09:32

View 2 revisions

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.

Chris Rorden

2020-07-15 22:26

reporter   ~0124065

 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.

Marco van de Voort

2020-07-16 10:40

manager   ~0124080

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

Issue History

Date Modified Username Field Change
2017-01-30 18:47 Chris Rorden New Issue
2017-01-30 18:47 Chris Rorden File Added:
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