Lazarus

Programming => Graphics and Multimedia => OpenGL => Topic started by: damieiro on December 15, 2019, 08:08:39 pm

Title: Provided GL, GLext librarys vs dglOpenGL
Post by: damieiro 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.

Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: marcov 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.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: damieiro 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
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: marcov 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.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: ChrisR 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.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: wp 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.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: ChrisR 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

Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: damieiro 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.  
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: marcov 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
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: avra 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.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: ChrisR 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 (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.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: marcov 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?
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: ChrisR 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.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: damieiro 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

Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: avra 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 (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.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: ChrisR on December 23, 2019, 04:29:35 pm
Avra,
  I did look at  pl_OpenGL - there are many nice demos that can provide a nice starting point for projects. I have two comments

1. The project '6e_raycast' is based on my code, specifically https://github.com/neurolabusc/vx but it does not include the BSD license. Note this is an old project, using legacy OpenGL. A modern version of this project using Core OpenGL is the render project I provide here https://github.com/neurolabusc/OpenGLCoreTutorials . Finally, an even more recent incarnation of this project is here https://github.com/neurolabusc/Metal-Demos/tree/master/volumerender - with this version being able to be compiled to Core OpenGL on Windows, Linux and MacOS as well as to Metal on MacOS. I would appreciate it if this project included the original license. Links to the modern projects would be helpful.

2. All the projects in pl_OpenGL use legacy OpenGL, with inefficient calls like glBegin/glEnd. I suspect legacy OpenGL will be supported on Windows for many years, and these are elegant demos. However, legacy OpenGL does not use the resources of the graphics card efficiently, and projects that use legacy OpenGL will me much harder to port to Metal/Vulkan than modern OpenGL core projects. Indeed, one can directly port OpenGL Core GLSL shaders to Vulkan's shader format. My Metal-Demos repository shows how one can compile to either Metal or OpenGL Core with relatively minimal changes in the code. Furthermore, users should be aware that legacy OpenGL will make cross platform difficult. First, MacOS will only support legacy OpenGL up to 2.1, so legacy projects on MacOS must not use any modern features. So MacOS users are forced to either choose legacy old OpenGL or modern Core OpenGL without the legacy features. The situation for GTK3 is even more strict: only OpenGL Core is supported when GTK3 detects a modern graphics system. Therefore, legacy OpenGL apps written in Lazarus that run fine using GTK2 will not run on GTK3 (another regression is that GTK3 does not support multi-sampling for OpenGL). This is unfortunate, Ubuntu 19.10 has removed default support for GTK2. Personally, I would recommend Lazarus Linux users who want to target OpenGL to use the QT5 widgetset, which does allow modern OpenGL to run in compatibility mode.

It is unfortunate that there have been so many forks in the high performance graphics world. Legacy OpenGL did make it easy to develop a basic 'Hello World' and helps users get familiar with the concepts. OpenGL Core requires shaders, and removes many of the nice helper functions for matrices. Vulkan takes this one step further, requiring the user to specify many low level details. While more recent APIs do allow higher performance, they do require a huge investment of time. Just like one can choose a high level language or a lower level language, one can choose the correct tool for the graphics they want.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: zeljko on December 23, 2019, 05:31:25 pm
Note that I'll make some major changes in Qt5 for OpenGL support because of https://bugs.freepascal.org/view.php?id=36342
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: avra on December 24, 2019, 08:29:42 am
The project '6e_raycast' is based on my code, specifically https://github.com/neurolabusc/vx but it does not include the BSD license
Is it OK if I add https://github.com/neurolabusc/vx/blob/master/license.txt to '6e_raycast' dir? I would automate that with my conversion script, and that will work as long as they keep that directory structure. If you give me a green light I will do it like that. I still think that you should also report that to PilotLogic forum, since I can not fix license violation in CodeTyphon (where I get pl_* components from). I can not do that because they banned me after seeing that I have made pl_* open source components available to Lazarus users.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: JernejL on April 13, 2020, 06:27:03 pm
Regarding original thread - i ended up making my own headers because i was dissattisfied with the state of both dopengl and lazarus's.
 
I think lazarus one can be put on right track, i'd much prefer that to dopengl.
 
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: Seenkao on October 18, 2020, 02:56:21 pm
Для понимания!
"Устаревший" OpenGL, давно удалён из OpenGL. В Версии 3.3 точно. Но! Это зависит от видеокарты пользователя.
На новых видеокартах "устаревший" OpenGL - эмулируется. Поэтому, в некоторых случаях, вы не потеряете в производительности используя "устаревший" OpenGL. Но! При этом, вы полностью сохраните совместимость со старыми видеокартами.

google translate:
For understanding!
"Deprecated" OpenGL, removed from OpenGL long ago. In Version 3.3, exactly. But! It depends on the user's video card.
On new video cards "outdated" OpenGL is emulated. Therefore, in some cases, you will not lose in performance using the "legacy" OpenGL. But! At the same time, you will fully maintain compatibility with old video cards.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: ChrisR on October 19, 2020, 01:09:08 pm
1. The license for my raycast project is included with the source project. It would be nice to have this included:
  https://github.com/neurolabusc/vx

2. I agree that for Linux and Windows (but not MacOS), you can mix-and-match legacy and modern OpenGL. These operating systems support OpenGL, and well coded legacy OpenGL can be as efficient as modern OpenGL. There are two reasons I prefer modern OpenGL. First, it abandons immediate mode, so the code only uses the efficient modes that better leverage GPU hardware. Second, it is a lot easier to port code to other platforms (MacOS, or handheld devices that use OpenGL ES).
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: Seenkao on October 19, 2020, 02:23:17 pm
Давайте смотреть объективно. Я ни кого не принуждаю использовать "устаревший" OpenGL и, так же не принуждаю пользоваться "новым".
Всё зависит от создаваемого приложения и от разработчика который будет выбирать, что ему использовать.

Но по поводу MacOS и OpenGL ES, я не совсем согласен, но "новый" OpenGL более совместим, только на начальном уровне, когда узнаёшь лучше, то вполне понимаешь, что OpenGL ES - это сильно урезанная версия OpeGL, и в любом случае, надо будет доделывать многое, для использования OpenGL ES как (вместо) OpenGL. Если, конечно, не использовать библиотеки, где это всё уже реализовано. Но опять же и в "устаревшем" OpenGL ES так же есть реализации OpenGL.
А MacOS, ни как не влияет, на OpenGL, кроме выбора версии OpenGL. А если выбран "устаревший" OpenGL, то тут уже зависит от того, какая видеокарта. Если старая, то будет работать немедленный доступ, если новая, то будет простая эмуляция "устаревшего" режима.

И, не стоит забывать, что на "устаревшем" OpenGL некоторые вещи мы в любом случае не сможем сделать, так как в "новом". :)

google translate:
Let's look objectively. I do not force anyone to use the "outdated" OpenGL, and I also do not force anyone to use the "new" one.
It all depends on the application being created and on the developer who will choose what to use.

But about MacOS and OpenGL ES, I don't quite agree, but the "new" OpenGL is more compatible, only at the initial level, when you get to know better, then you quite understand that OpenGL ES is a heavily stripped-down version of OpeGL, and in any case, it is necessary will do a lot to use OpenGL ES as (instead of) OpenGL. Unless, of course, you use libraries where all this has already been implemented. But again, the "legacy" OpenGL ES also has OpenGL implementations.
And MacOS doesn't affect OpenGL in any way, except for the choice of the OpenGL version. And if "outdated" OpenGL is selected, then it already depends on what video card. If an old video card, then immediate access will work, if a new one, then there will be a simple emulation of the "outdated" mode.

And, do not forget that on the "outdated" OpenGL we will not be able to do some things anyway, as in the "new" one. :)
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: avra on October 21, 2020, 11:17:59 am
The project '6e_raycast' is based on my code, specifically https://github.com/neurolabusc/vx but it does not include the BSD license
Is it OK if I add https://github.com/neurolabusc/vx/blob/master/license.txt to '6e_raycast' dir? I would automate that with my conversion script, and that will work as long as they keep that directory structure. If you give me a green light I will do it like that. I still think that you should also report that to PilotLogic forum, since I can not fix license violation in CodeTyphon (where I get pl_* components from). I can not do that because they banned me after seeing that I have made pl_* open source components available to Lazarus users.
I did not receive a reply from ChrisR neither here neither via PM, so I will delete '6e_raycast' directory from pl_opengl package examples in new ct4laz. If someone has an objection for any other directory or package, please report it.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: ChrisR on October 27, 2020, 06:46:11 pm
You are free to use my code as long as you respect the license. The included license is a simple BSD 2-Clause license, which requires you to include the license when you share the code.
  https://opensource.org/licenses/BSD-2-Clause
This is a permissive license that is fully compatible with sharing. You can even use my code in professional projects without paying me anything, as long as you include the license.
Title: Re: Provided GL, GLext librarys vs dglOpenGL
Post by: avra on October 28, 2020, 08:30:19 am
You are free to use my code as long as you respect the license. The included license is a simple BSD 2-Clause license, which requires you to include the license when you share the code.
  https://opensource.org/licenses/BSD-2-Clause
This is a permissive license that is fully compatible with sharing. You can even use my code in professional projects without paying me anything, as long as you include the license.
I have already finished packing pl_opengl for new ct4laz and '6e_raycast' dir is excluded. If you have any other directory that you wish excluded please say so. If you give me your mail in private message, I can send you pl_opengl for full check before official release. There will also be RC candidate available for a while.

At the end I have decided not to be the one who should fix this specific CodeTyphon licensing issue, and as with all previously known cases I will exclude reported code from ct4laz. So, the real address for fixing issues will be PilotLogic. Once they have your license back into sources - I can include that dir again.
TinyPortal © 2005-2018