Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2018-09

Announcement GLPT

17 messages · 8 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Darius Blaszyk

Hi all,

I committed GLPT or the OpenGL Pascal Toolkit just now on GitHub. This toolkit is a (free) pascal replacement for GLUT and other similar toolkits that depend on third party dynamic libraries. I have been using this library in a couple of projects and decided to publish under the MIT license. This toolkit allows detailed control over the event loop, a big annoyance when working with GLUT.

The toolkit is quite workable for Windows and Linux. Mac is missing but I'm hoping to receive pull requests now it's published.

https://github.com/daar/GLPT

Enjoy!

Rgds, Darius

Reply by email

Graeme Geldenhuys
to Darius Blaszyk
Darius Blaszyk wrote
I committed GLPT or the OpenGL Pascal Toolkit just now on GitHub. This toolkit is a (free) pascal replacement for GLUT and other similar toolkits that depend on third party dynamic libraries.

Sounds awesome. Thanks for sharing the code. I'll definitely be taking a ,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Anthony Walter
to Darius Blaszyk: I committed GLPT or the OpenGL Pascal Toolkit just now on GitHub. This toolkit is a…

Darius,

I read you message and checked the git repository. I didn't find the answers to a few questions I had by browsing you source, so I'll ask them here. Also, I have some comments.

First questions:

Do you support requesting context types, such as OpenGL ES 2.0 versus OpenGL 3.1?
Do you support callback stubs for querying extension strings and loading extension functions?
Do you provide a curated list of available OpenGL functions and related constants and types?
Repeat question above, but for all GL extensions and extension constant and types?
Do you support enumerating available exclusive resolution modes and switching between modes after a context has been created? Do you provide a platform independent high resolution timer?

Comments:

I noticed you are using the Classes unit inside GLPT. Would it be possible to remove this reference? In some situations users might not want to use that unit (which also causes SysUtils to be used) because they desire to implement their own exception base types or other RTL functions or types. You really shouldn't be using Classes for a base library like you're implementing.

I noticed you are using the existing Free Pascal GL unit. If you are planning to support OpenGL context types, it might be better to separate OpenGL functions into different curated units. Units that expose only the functionality, plus extensions, of a specific context type. This way users cannot accidentally use functions unsupported by the context they requested.

Example:

unit GL30; // defines all the functions and types required by OpenGL 3.0
unit GLES20; // defines all the functions and types required by OpenGL ES
2.0, excludes many normal GL functions
unit GLES30; // defines all the functions and types required by OpenGL ES
3.0, excludes many normal GL functions

Then users can define a macros {$define GL=GLES20} and can switch APIs for either testing or development purposes. The separated units with different functions and types can then easily reveal differences between APIs and also possibly the subtle differences between how they work.

Reply by email

Darius Blaszyk
to Anthony Walter

Hi Anthony,

Thanks for your tip! I just committed some code that removes the Classes, SysUtils and GL units from GLPT. This is indeed better and cleaner.

As for your questions about supporting different GL versions. GLPT only creates a native GL context and hides some of the platform specific code for the developer. As far as I am concerned there is no interaction with specific GL versions or extensions or whatever. But I could be wrong here, please correct me in that case. On my whish list (next to Mac support) are indeed resolution modes, monitor support, timer and a number of other items. I'm open for pull requests to speed up the progress :).

Looking forward for other suggestions and some use cases of course.

https://github.com/daar/GLPT

Rgds, Darius

PM Anthony Walter wrote 51 lines
Darius, I read you message and checked the git repository. I didn't find the answers to a few questions I had by browsing you source, so I'll ask them here. Also, I have some comments. First questions: Do you support requesting context types, such as OpenGL ES 2.0 versus OpenGL 3.1? Do you support callback stubs for querying extension strings and loading extension functions? Do you provide a curated list of available OpenGL functions and related constants and types? Repeat question above, but for all GL extensions and extension constant and types? Do you support enumerating available exclusive resolution modes and switching between modes after a context has been created? Do you provide a platform independent high resolution timer? Comments: I noticed you are using the Classes unit inside GLPT. Would it be possible to remove this reference? In some situations users might not want to use that unit (which also causes SysUtils to be used) because they desire to implement their own exception base types or other RTL functions or types. You really shouldn't be using Classes for a base library like you're implementing. I noticed you are using the existing Free Pascal GL unit. If you are planning to support OpenGL context types, it might be better to separate OpenGL functions into different curated units. Units that expose only the functionality, plus extensions, of a specific context type. This way users cannot accidentally use functions unsupported by the context they requested. Example: unit GL30; // defines all the functions and types required by OpenGL 3.0 unit GLES20; // defines all the functions and types required by OpenGL ES 2.0, excludes many normal GL functions unit GLES30; // defines all the functions and types required by OpenGL ES 3.0, excludes many normal GL functions Then users can define a macros {$define GL=GLES20} and can switch APIs for either testing or development purposes. The separated units with different functions and types can then easily reveal differences between APIs and also possibly the subtle differences between how they work. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Anthony Walter
to Darius Blaszyk

Darius,

Well the big main thing about glut, or sdl, or whatever bare bones framework used to create an OpenGL window are the following things:

1) Abstracting creating a window
2) Abstracting associating of a GL context with the widow
3) Abstracting the event loop
4) Abstracting reading mouse, keyboard, and terminate events

Regarding point #2, you really ought to consider allowing a specific context type, or profile, to be created, given core or es profile and a version.

In Free Glut this is done through:

glutInitContextVersion(4, 1);
glutInitContextProfile(GLUT_CORE_PROFILE);

With SDL this is done through:

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);

Both of these are done in either API before the GL context is created. Essentially what they do is allow you the programmer to decide what type of context you are creating. In the case of the Free Glut example I am asking for an OpenGL 4.1 context. In the SDL example I am asking for an OpenGL ES 2.0 context.

These context profiles are important for a number of reasons. One reason is that they frequently determine which vendor dll (shared object on Mac and Linux) and implementation are dlls not only
require their own specific and distinct functions to load extensions, but they also operate differently. For example, the GLSL shader compiler on OpenGL 2.1 context may operate totally differently than the GLSL shader compiler on OpenGL 4.1.

Anyhow, the gist of all this is, you ought to provide the ability to allow the programmer ask for a profile, major and minor version. You ought to attempt to create the requested context type, load the API for the user based on the requested profile and version, and provide an abstracted stub that is filled out for properly to loading extensions for of the selected profiles and version.

Finally, you ought to detect when a profile failed to load, and gracefully fail when the context cannot be created. For example if the programmer requests OpenGL 4.1, and either the drivers for that version are not present, or the hardware doesn't Support 4.1, you should return 0 or nil when trying to create the context, and possibly have an error system so that the programmer can determine what went wrong. That is, an error message returns as a string with the words "The request context version 4.1 could not be created".

if Context = 0 then
begin
  S := GLPT_GetLastError;
  WriteLn(S)
  Exit;
end;

Might result in this line written to the terminal:

The request context version 4.1 could not be created

Reply by email

Darius Blaszyk
to leledumbo

Indeed, it resembles GLFW more, but also GHOST and fpGui to some extent. Even better, GLPT is still in development and it's 100% pascal. As far as I'm concerned it still malleable and should result in a mature alternative to any other library.

On Tue, Sep 25, 2018 at 5:27 AM leledumbo via fpc-pascal <

Show quoted text 14 lines
wrote: > https://github.com/daar/GLPT This is more GLFW rather than GLUT. Good, I prefer it this way as I have much greater control with regards to the event handling. -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

R0b0t1
to Dennis
Darius Blaszyk wrote 9 lines
Hi all, I committed GLPT or the OpenGL Pascal Toolkit just now on GitHub. This toolkit is a (free) pascal replacement for GLUT and other similar toolkits that depend on third party dynamic libraries. I have been using this library in a couple of projects and decided to publish under the MIT license. This toolkit allows detailed control over the event loop, a big annoyance when working with GLUT.

Noice. It reminds me quite a bit of SDL2, which is a very well designed library.

Are multiplexing synchronization primitives available? E.g. select(2) but for keyboard/mouse/window events.

Dennis wrote 5 lines
How can I use opengl within my lazarus UI program? I want to embed such an opengl window inside a TPanel, and in its Paint method, do the opengl rendering. Is that possible? How?

This seems to be the obvious usecase. Can some clarification be provided? E.g. SDL2 needs to manage the OpenGL contexts, does this library manage them as well?

Cheers,
R0b0t1

Reply by email

Anthony Walter
to Dennis: Thanks for your contribution. Just tried out your sample, they are nice. How can I use…

Dennis,

If you want to embed OpenGL in your window, then there is already TOpenGLControl. It's included with Lazarus and is in the components folder.

More here:

http://wiki.freepascal.org/OpenGL_Tutorial

This library is not meant for embedding, it is meant as a native toolkit to create a window and associate an OpenGL context on multiple platforms. The same as GLUT or SDL, but without the dll / shared library dependency. If written correctly, it would also provide a bit more ease of use because it would also expose native Pascal types, rather than standard C types.

Examples of improvements with Pascal types over C types might include:

Pascal sets and enumerations instead of C int bit flags. Pascal style events instead of C style callbacks.
Pascal style interfaces instead of C style records.

Such as this arbitrary made up code:

Window.Style := [wsBorderless, wsCentered];
Window.OnMouseMove := MouseMoveHandler;
Frame := Window as IFrame;

Reply by email

Dennis
to Anthony Walter
Anthony Walter wrote 8 lines
Dennis, If you want to embed OpenGL in your window, then there is already TOpenGLControl. It's included with Lazarus and is in the components folder. More here:

Thanks a lot.
I tried it but found that drawing text in OpenGL seems to be problematic. Is there anyway to draw text using windows' existing font? Or is there a library for nicer vector based font?
Dennis

Reply by email

Darius Blaszyk
to R0b0t1: Noice. It reminds me quite a bit of SDL2, which is a very well designed library. Are…
AM R0b0t1 wrote
Are multiplexing synchronization primitives available? E.g. select(2) but for keyboard/mouse/window events.

Multithreading is not available, however I'm open for suggestions and pull requests.

This seems to be the obvious usecase. Can some clarification be provided? E.g. SDL2 needs to manage the OpenGL contexts, does this library manage them as well?

OpenGL context management is not yet implemented. Until now I did not have a need for this functionality, but if someone can provide some code or make a pull request I will add this.

Rgds, Darius

Reply by email

Darius Blaszyk
to Dennis: Thanks a lot. I tried it but found that drawing text in OpenGL seems to be problematic.…
PM Dennis wrote
I tried it but found that drawing text in OpenGL seems to be problematic. Is there anyway to draw text using windows' existing font? Or is there a library for nicer vector based font?

There is a unit called uglyfont.pas included in Lazarus. I ported it some time ago for an imgui implementation example. This is a simple vector font. You can also implement a freetype font fairly easy. In fact I can share some code. Just search for NeHe and you will find it online as well.

Although GLUT came with standard fonts I am not inclined to include a font in GLPT soon. Same for menu, UI and other drawing stuff. This should be handled one level higher up.

Rgds, Darius

Reply by email

Dennis Poon
to Darius Blaszyk
Darius Blaszyk wrote 20 lines
On Tue, Sep 25, 2018 at 5:21 PM Dennis < > wrote: I tried it but found that drawing text in OpenGL seems to be problematic. Is there anyway to draw text using windows' existing font? Or is there a library for nicer vector based font? There is a unit called uglyfont.pas included in Lazarus. I ported it some time ago for an imgui implementation example. This is a simple vector font. You can also implement a freetype font fairly easy. In fact I can share some code. Just search for NeHe and you will find it online as well. Although GLUT came with standard fonts I am not inclined to include a font in GLPT soon. Same for menu, UI and other drawing stuff. This should be handled one level higher up.

I am writing a Chinese program and the Chinese character set is huge with many thousand of characters, and each character has many strokes. I think the work required is too daunting and the improvement in speed is not that much for my simple chart plotting use.

I will stay with Lazarus UI for the moment. In future, I might explore fpGUI instead.

Dennis

Reply by email

Darius Blaszyk
to Dennis Poon
> There is a unit called uglyfont.pas included in Lazarus. I ported it

I Dennis, I ported the Lazarus imgui example to GLPT today and committed it to GitHub. You will also find the font library in the examples folder.

Rgds, Darius

Reply by email

Ryan Joseph
to Darius Blaszyk: I committed GLPT or the OpenGL Pascal Toolkit just now on GitHub. This toolkit is a…
On Sep 23, 2018, at 10:47 PM, Darius Blaszyk wrote: The toolkit is quite workable for Windows and Linux. Mac is missing but I'm hoping to receive pull requests now it's published.

I support you in this so I’ll try to make a Mac implementation since I already have Cocoa/Objective Pascal OpenGL code. I switched to SDL because I was tired of maintaining the context layer but the old is still there if I look for it. I have iOS also but I didn’t see you supporting mobile platforms yet.

Regards,
Ryan Joseph

Reply by email