Announcement GLPT

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Announcement GLPT

Darius Blaszyk-2
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.


Enjoy!

Rgds, Darius

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Graeme Geldenhuys-6
On 23/09/18 16:47, 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
look at it.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Darius Blaszyk-2

> Sounds awesome. Thanks for sharing the code. I'll definitely be taking a
> look at.

You will notice in that case that some inspiration came from fpGui as well :). Cheers...

Darius
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Anthony Walter-3
In reply to this post by Darius Blaszyk-2
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Darius Blaszyk-2
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.


Rgds, Darius

On Mon, Sep 24, 2018 at 4:53 PM Anthony Walter <[hidden email]> wrote:
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Anthony Walter-3
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 loaded at runtime. Theses 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Free Pascal - General mailing list
In reply to this post by Darius Blaszyk-2
> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Darius Blaszyk-2
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 <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Dennis
In reply to this post by Darius Blaszyk-2
Thanks for your contribution.
Just tried out your sample, they are nice.


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?

Dennis


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

R0b0t1
On Sun, Sep 23, 2018 at 5:47 PM, Darius Blaszyk <[hidden email]> wrote:
> 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.


On Tue, Sep 25, 2018 at 11:43 AM, Dennis <[hidden email]> wrote:
> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Anthony Walter-3
In reply to this post by Dennis
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:


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;


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Dennis


Anthony Walter wrote:
> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Darius Blaszyk-2
In reply to this post by R0b0t1
On Tue, Sep 25, 2018 at 11:52 AM R0b0t1 <[hidden email]> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Darius Blaszyk-2
In reply to this post by Dennis
On Tue, Sep 25, 2018 at 5:21 PM Dennis <[hidden email]> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Dennis Poon


Darius Blaszyk wrote:

> On Tue, Sep 25, 2018 at 5:21 PM Dennis <[hidden email]
> <mailto:[hidden email]>> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Darius Blaszyk-2

> 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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Announcement GLPT

Ryan Joseph
In reply to this post by Darius Blaszyk-2


> On Sep 23, 2018, at 10:47 PM, Darius Blaszyk <[hidden email]> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal