Recent

Author Topic: Provided GL, GLext librarys vs dglOpenGL  (Read 13603 times)

damieiro

  • Full Member
  • ***
  • Posts: 200
Provided GL, GLext librarys vs dglOpenGL
« on: December 15, 2019, 08:08:39 pm »
Hi!

I'm starting now with Open GL 3.3+
I was trying some simple like this with SDL2: https://www.freepascal-meets-sdl.net/chapter-10-sdl-modern-opengl/
And now i'm reading some modern opengl tutorial like this: https://wiki.delphigl.com/index.php/Lazarus_-_OpenGL_3.3_Tutorial
Well, i go for standalone program like in the SDL tutorial, without use of lazarus (only FreePascal)

When i was analyzing the code, i saw these differences:

1.- GL and GL ext seems to be up to version 4.0. It seems pure header conversion and seems supported partially by lazarus crew
2.- dslOpenGL claims that their headers are bug free and are pure header conversion too and default lazarus gl libraries are buggy. It seems supported to 4.5 and have a support team. https://wiki.delphigl.com/index.php/dglOpenGL.pas/en

Initializing these two library shows differences...
- Types aren't exactly the same. And constants seems not having exactly the same type
- dglOpenGL seems to have their own way to initilize
- dglOpenGL seems to need lazarus on their default (takes the form handle from lazarus, so for non gui or non-lazarus-gui like sdl seems to make their own context.

My question: What headers are you using and why?
What are these headers support?
What should i use, assuming i will not using lazarus forms?

Well, why am I asking this?
Because it doesn't seems some header interoperability. If you use (for example) SDL2 headers, you can use some (for example Jedi ones), and
replace these for others and don't expect very big trouble. In this case, if you (for example), change the GL and GLext header for dglOpenGL, it will simply not work and seems to be needed a translation work. I do not understand why ones are better than others and things like that as claims dglopengl for their headers.

« Last Edit: December 15, 2019, 09:32:13 pm by damieiro »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #1 on: December 15, 2019, 08:56:40 pm »
I'm using dglopengl in my work application.

Reasons: I also use Delphi, they are mostly up to date, there is lot of code to find that uses them. I don't use SDL.

damieiro

  • Full Member
  • ***
  • Posts: 200
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #2 on: December 15, 2019, 09:36:22 pm »
thx Marcov:

Did you have used GL and GLext?
If answer is Yes, is there Big difference besides header actualization?. In fast read these seems not equal

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #3 on: December 15, 2019, 09:45:41 pm »
thx Marcov:

Did you have used GL and GLext?

The Opengl parts of the Delphi application I have was based on a Opengl concept demo by Ales Katona in 2008-2009, using those headers. I don't exactly if he or I changed to the dglopengl headers.  Maybe for the font support ? But they were more out of sync in the past, than now.

Even though I have rewritten the whole opengl codebase in 2016-2018, I still use Windows specific opengl font support (wglusebitmapfont())

Quote
If answer is Yes, is there Big difference besides header actualization?. In fast read these seems not equal

As said, mind share. Plenty of Delphi code and examples to find.
« Last Edit: December 15, 2019, 10:23:46 pm by marcov »

ChrisR

  • Full Member
  • ***
  • Posts: 247
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #4 on: December 15, 2019, 10:16:43 pm »
If you wish to use OpenGL Core specification using Lazarus you have three options:
 1. GL, GLext are included with FreePascal
 2. dglOpenGL
 3. glcorearb
The first two will support OpenGL legacy calls as well as modern OpenGL calls. The third option only supports modern OpenGL core functions. Since Linux and Windows support modern OpenGL with compatibility mode (core and legacy calls), you can choose any library. However, if you want to target Linux, Windows and MacOS, you should use glcorearb. MacOS supports legacy OpenGL functions only to OpenGL 2.1, while recent versions of OpenGL must be limited to the core specification.

Here are some Lazarus Core OpenGL demos that compile on MacOS, Linux and Windows.
  https://github.com/neurolabusc/OpenGLCoreTutorials
They will work with the Windows, Cocoa (MacOS), GTK2, QT5, and GTK3 widget sets.

wp

  • Hero Member
  • *****
  • Posts: 11853
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #5 on: December 15, 2019, 10:19:45 pm »
I'm only an occasional OpenGL user, and so far it has been ok to stick to gl/glext. The OpenGL drawer of TAChart uses them, and my own 3d-Chart experiments (https://github.com/wp-xyz/OpenGLChart) are fine with them, too. But, of course, these are no high-end applications of OpenGL.

ChrisR

  • Full Member
  • ***
  • Posts: 247
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #6 on: December 15, 2019, 10:40:19 pm »
The GL/GLext units are fine as long as you either never target MacOS, or never target MacOS with features that exceed OpenGL 2.1.

As a developer, the challenge for GL/GLext is that it includes both legacy and modern OpenGL calls. While this is fine for Linux and Windows (where you can mix and match legacy OpenGL and modern OpenGL), it does not alert the developer to legacy OpenGL calls that may have poor performance and will crash MacOS if MacOS is requested to use OpenGL version later than 2.1. Using glcorearb only expose modern OpenGL functions, preventing a developer from accidentally using a legacy function.

Here is another Lazarus demo:
  https://github.com/neurolabusc/plyview

Since the original poster mentions wanting to learn modern OpenGL, I would suggest restricting yourself to the modern calls. It will also help if you ever want to target Vulkan, OpenGL ES or Metal, as those shading languages are very similar to OpenGL core and do not include equivalents for most legacy features. A nice example of this are these Lazarus demos that can be compiled for OpenGL Core on Windows, Linux or MacOS as well as targeting Metal for MacOS
  https://github.com/neurolabusc/Metal-Demos

« Last Edit: December 15, 2019, 10:44:01 pm by ChrisR »

damieiro

  • Full Member
  • ***
  • Posts: 200
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #7 on: December 15, 2019, 11:13:00 pm »
Well, really i'm a really newbie on modern openGL.
Many thanks for your responses. These help me a lot. And I'm reading the ChrisR tutorials and the german ones

And i'm using SDL for making context. I do not know if this is correct in modern OPENGL, but i'm used not to use GUI

For example, this is my own "actual test" of using
https://www.freepascal-meets-sdl.net/chapter-10-sdl-modern-opengl/
with dglopenGL. Only a few changes. As i saw, i can enforce with sdlopenGL only modern calls. I have to try  glcorearb
Actually this code works (it needs the vertexshader.txt and fragmentshader.txt).

I figure I'm starting a loong path to manage it, but i want to test it.

Note: This needs SDL2 headers (i used jedi ones) and SDL2 installed. I do not know if SDL&ModernGL will target more or less. I will read your examples that targets windows, linux & mac (do work with android?)

Code: Pascal  [Select][+][-]
  1. program openGLModerno;
  2.  
  3. uses Classes, SysUtils, SDL2,
  4.   dglOpenGL;
  5.  
  6.  
  7. const
  8.   vertexShaderFile = 'VertexShader.txt';
  9.   fragmentShaderFile = 'FragmentShader.txt';
  10.   triangleData: array[0..8] of GLfloat = ( -1.0, -1.0, 0.0,
  11.                                             1.0, -1.0, 0.0,
  12.                                             0.0,  1.0, 0.0  );
  13.  
  14. var
  15. sdlWindow1: PSDL_Window;
  16. sdlGLContext1: TSDL_GLContext;
  17. i: Word;
  18. VertexArrayID: GLuint;
  19. triangleVBO: GLuint;
  20.  
  21. VertexShaderID: GLuint;
  22. VertexShaderCode: PGLchar;
  23. FragmentShaderID: GLuint;
  24. FragmentShaderCode: PGLchar;
  25. ShaderCode: TStringList;
  26. ProgramID: GLuint;
  27. compilationResult: ByteBool;
  28. InfoLogLength: GLint;
  29. ErrorMessageArray: array of Char;
  30.  
  31.  
  32.  
  33. begin
  34.  
  35.   compilationResult:= GL_FALSE;
  36.  
  37.   if SDL_Init( SDL_INIT_VIDEO ) < 0 then HALT;
  38.  
  39.   //get an OpenGL window and create OpenGL context - INSTEAD of
  40.   sdlWindow1 := SDL_CreateWindow( 'OpenGL window', 50, 50, 500, 500, SDL_WINDOW_OPENGL );
  41.   if sdlWindow1 = nil then HALT;
  42.  
  43.   sdlGLContext1 := SDL_GL_CreateContext( sdlWindow1 );
  44.   if @sdlGLContext1 = nil then HALT;
  45.  
  46.   //init OpenGL and load extensions
  47.   InitOpenGL; // Don't forget, or first gl-Call will result in an access violation!
  48.   ReadExtensions;
  49.  
  50.  
  51.   //print out OpenGL vendor, version and shader version
  52.   writeln( 'Vendor: ' + glGetString( GL_VENDOR ) );
  53.   writeln( 'OpenGL Version: ' + glGetString( GL_VERSION ) );
  54.   writeln( 'Shader Version: ' + glGetString( GL_SHADING_LANGUAGE_VERSION ) );
  55.  
  56.   //create Vertex Array Object (VAO)
  57.   glGenVertexArrays( 1, @VertexArrayID );
  58.   glBindVertexArray( VertexArrayID );
  59.  
  60.   //creating Vertex Buffer Object (VBO)
  61.   glGenBuffers( 1, @triangleVBO );
  62.   glBindBuffer( GL_ARRAY_BUFFER, triangleVBO );
  63.   glBufferData( GL_ARRAY_BUFFER, SizeOf( triangleData ), @triangleData, GL_STATIC_DRAW );
  64.  
  65.   //creating shaders
  66.   VertexShaderID := glCreateShader( GL_VERTEX_SHADER );
  67.   FragmentShaderID := glCreateShader( GL_FRAGMENT_SHADER );
  68.  
  69.   //load shader code and get PChars
  70.   ShaderCode := TStringList.Create;
  71.   ShaderCode.LoadFromFile( VertexShaderFile );
  72.   VertexShaderCode := ShaderCode.GetText;
  73.   if VertexShaderCode = nil then HALT;
  74.   ShaderCode.LoadFromFile( FragmentShaderFile );
  75.   FragmentShaderCode := ShaderCode.GetText;
  76.   if FragmentShaderCode = nil then HALT;
  77.   ShaderCode.Free;
  78.  
  79.   //compiling and error checking vertex shader
  80.   write('Compiling and error checking Vertex Shader... ' );
  81.   glShaderSource( VertexShaderID, 1, @VertexShaderCode, nil );
  82.   glCompileShader( VertexShaderID );
  83.  
  84.   glGetShaderiv( VertexShaderID, GL_COMPILE_STATUS, @compilationResult );
  85.   glGetShaderiv( VertexShaderID, GL_INFO_LOG_LENGTH, @InfoLogLength );
  86.   if compilationResult = GL_FALSE then
  87.   begin
  88.     writeln( 'failure' );
  89.     SetLength( ErrorMessageArray, InfoLogLength+1 );
  90.     glGetShaderInfoLog( VertexShaderID, InfoLogLength, nil, @ErrorMessageArray[0] );
  91.     for i := 0 to InfoLogLength do write( String( ErrorMessageArray[i] ) );
  92.     writeln;
  93.   end else writeln( 'success' );
  94.  
  95.   //compiling and error checking fragment shader
  96.   write('Compiling and error checking Fragment Shader... ' );
  97.   glShaderSource( FragmentShaderID, 1, @FragmentShaderCode, nil );
  98.   glCompileShader( FragmentShaderID );
  99.  
  100.   glGetShaderiv( FragmentShaderID, GL_COMPILE_STATUS, @compilationResult );
  101.   glGetShaderiv( FragmentShaderID, GL_INFO_LOG_LENGTH, @InfoLogLength );
  102.   if compilationResult = GL_FALSE then
  103.   begin
  104.     writeln( 'failure' );
  105.     SetLength( ErrorMessageArray, InfoLogLength+1 );
  106.     glGetShaderInfoLog( VertexShaderID, InfoLogLength, nil, @ErrorMessageArray[0] );
  107.     for i := 0 to InfoLogLength do write( String( ErrorMessageArray[i] ) );
  108.     writeln;
  109.   end else writeln( 'success' );
  110.  
  111.   //creating and linking program
  112.   write('Creating and linking program... ' );
  113.   ProgramID := glCreateProgram();
  114.   glAttachShader( ProgramID, VertexShaderID );
  115.   glAttachShader( ProgramID, FragmentShaderID );
  116.   glLinkProgram( ProgramID );
  117.  
  118.   glGetShaderiv( ProgramID, GL_LINK_STATUS, @compilationResult );
  119.   glGetShaderiv( ProgramID, GL_INFO_LOG_LENGTH, @InfoLogLength );
  120.   if compilationResult = GL_FALSE then
  121.   begin
  122.     writeln( 'failure' );
  123.     SetLength( ErrorMessageArray, InfoLogLength+1 );
  124.     glGetShaderInfoLog( VertexShaderID, InfoLogLength, nil, @ErrorMessageArray[0] );
  125.     for i := 0 to InfoLogLength do write( String( ErrorMessageArray[i] ) );
  126.     writeln;
  127.   end else writeln( 'success' );
  128.  
  129.  
  130.  
  131.   for i := 0 to 400 do
  132.   begin
  133.     glClearColor( 0.0, 1.0-i/400, 0.0+i/400, 1.0 );
  134.     glClear( GL_COLOR_BUFFER_BIT );
  135.     glUseProgram( ProgramID );
  136.     glEnableVertexAttribArray( 0 );
  137.     glBindBuffer( GL_ARRAY_BUFFER, triangleVBO );
  138.     glVertexAttribPointer( 0, 3, GL_FLOAT, GL_FALSE, 0, nil );
  139.     glDrawArrays( GL_TRIANGLES, 0, 3 );
  140.     glDisableVertexAttribArray( 0 );
  141.     SDL_Delay( 20 );
  142.     SDL_GL_SwapWindow( sdlWindow1 );
  143.   end;
  144.  
  145.   //clean up
  146.   glDetachShader( ProgramID, VertexShaderID );
  147.   glDetachShader( ProgramID, FragmentShaderID );
  148.  
  149.   glDeleteShader( VertexShaderID );
  150.   glDeleteShader( FragmentShaderID );
  151.   glDeleteProgram( ProgramID );
  152.  
  153.   StrDispose( VertexShaderCode );
  154.   StrDispose( FragmentShaderCode );
  155.  
  156.   glDeleteBuffers( 1, @triangleVBO );
  157.   glDeleteVertexArrays( 1, @VertexArrayID );
  158.  
  159.   //SLD_clean
  160.   SDL_GL_DeleteContext( sdlGLContext1 );
  161.   SDL_DestroyWindow( sdlWindow1 );
  162.  
  163.   SDL_Quit;
  164. end.
  165.  
« Last Edit: December 16, 2019, 12:49:42 am by damieiro »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #8 on: December 16, 2019, 06:01:12 pm »
Well, really i'm a really newbie on modern openGL.
Many thanks for your responses. These help me a lot. And I'm reading the ChrisR tutorials and the german ones

And i'm using SDL for making context. I do not know if this is correct in modern OPENGL, but i'm used not to use GUI

See the first post in this thread: https://forum.lazarus.freepascal.org/index.php/topic,30556.msg194484.html#msg194484

it is an old unit test for signed distance fonts (not so nice back then, before subsampling was implemented), but it does demonstrate creating an canvas with just dglopengl

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #9 on: December 17, 2019, 08:57:49 am »
If you wish to use OpenGL Core specification using Lazarus you have three options:
 2. dglOpenGL
You can find it in OPM under the name pl_OpenGL. It is cross platform and has lots of demos. There are also GLScene, pl_OpenGLES, and pl_Vulkan packages.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

ChrisR

  • Full Member
  • ***
  • Posts: 247
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #10 on: December 17, 2019, 04:35:09 pm »
Quote
pl_OpenGL. It is cross platform and has lots of demos

pl_OpenGL seems an interesting option. The current version can not be installed on the SVN for MacOS, so I can not evaluate it fully. However, it does seem like several of the suggestions I made for allowing OpenGL to run on MacOS have been incorporated. I would still prefer glcorearb over this as it ensures projects will be cross-platform, the pl_OpenGL assumes compatibility mode, so developers will need to be very cautious.

While it does include several demos, many of them are not compatible with the OpenGL core profile. These are not cross platform as they can not run in MacOS with any functions greater than OpenGL 2.1. Many of those that are Core profile compatible were written by me (https://github.com/neurolabusc/OpenGLCoreTutorials), and copied into this project without copying the license. I provide these under the permissive BSD 2-Clause license which allows redistribution, and indeed I would encourage including these examples in this package to provide regression testing. However, these projects must include my license. The authors include the MPL2 license, which is great. It is fine to include BSD code into a MPL project, but the BSD license must be retained. I realize that acknowledging licenses is a burden for open source developers, but it does ensure that the wishes of the original developers are respected.

Regardless, this looks like a promising option and I would be happy to contribute to testing and enhancing it if the developers can support building it on the Lazarus MacOS svn.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #11 on: December 17, 2019, 05:24:00 pm »
How is the future of OpenGL on OS X? Any changes with the recent round of new OS X updates?

ChrisR

  • Full Member
  • ***
  • Posts: 247
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #12 on: December 17, 2019, 08:23:14 pm »
Marcov,
 While Apple has deprecated OpenGL, modern OpenGL is pretty close to Metal. Take a look at these Lazarus demos:
  https://github.com/neurolabusc/Metal-Demos
each can be compiled to run
  MacOS Cocoa: Metal
  MacOS Cocoa: OpenGL
  Linux GTK2, QT5, GTK3: OpenGL
  Windows: OpenGL
Apple deprecated 32-bit applications about a decade before it was no longer supported. Perhaps they will switch to ARM CPUs in a shorter timeframe, which would cause a lot of issues for OpenGL projects as well as Lazarus projects. As I note on that repository, Metal on Intel CPUs is crippled relative to Metal on ARM CPUs.

damieiro

  • Full Member
  • ***
  • Posts: 200
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #13 on: December 17, 2019, 10:18:59 pm »
another related question...
should i go for vulkan?
I never used vulkan, but i'm seeing examples like this: https://github.com/james-mcjohnson/VulkanLibraryForFreePascal

And are using SDL like me.

It seems to be cross-platform.

And i (by my own convictions) will not develop to metal or some closed system unless there isn't another option.

And i do not know if modern opengl will be the right option in some years... But it seems like Assembly (vulkan) vs C (OpenGL). I do not know if Vulkan is really a step forward...

And seeing amazing works like BeRo like this https://github.com/BeRo1985/pasvulkan i think vulkan seems overcomplicated for what i'm trying

« Last Edit: December 18, 2019, 12:44:15 am by damieiro »

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Provided GL, GLext librarys vs dglOpenGL
« Reply #14 on: December 18, 2019, 07:58:31 pm »
Many of those that are Core profile compatible were written by me (https://github.com/neurolabusc/OpenGLCoreTutorials), and copied into this project without copying the license. I provide these under the permissive BSD 2-Clause license which allows redistribution, and indeed I would encourage including these examples in this package to provide regression testing. However, these projects must include my license. The authors include the MPL2 license, which is great. It is fine to include BSD code into a MPL project, but the BSD license must be retained.
According to https://www.pilotlogic.com/sitejoom/index.php/wiki?id=198 it seams that pl_OpenGL indeed does not support Mac. As you can see, it is a package found in CodeTyphon which is a PilotLogic's fork of Lazarus. They converted lots of Delphi packages and many can not be found else where. However they have decided to break Lazarus compatibility, which I didn't like, so you can see from my signature that I have converted their pl_* packages back to Lazarus, and some of them can be even downloaded with OPM. PilotLogic is not famous for understanding how much keeping original licensing info is important. They kept some, but some they have deleted. It is not that important if original license does not enforce them to do so, but in this particular case BSD2 is very strict saying that copyright and license MUST be included. It would be best if you report such violation directly to PilotLogic forum. We don't have to wait for their response, so I can either remove it from OPM immediately, or if it is just a matter of adding some files then I can add them to my ct2laz script without waiting for their action. If you have a better suggestion then please say so. Unfortunately, this is not a first problem with their packages and I already had to exclude some in the past.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

 

TinyPortal © 2005-2018