GLPT v0.1.1 released

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

GLPT v0.1.1 released

Darius Blaszyk-2
Hi all,

I just released the first complete version of GLPT. Thanks to Ryan Joseph GLPT now supports Linux, MacOSX and Windows. Anyone interested in the project is invited to test, use, discuss and code. Please submit found or proposed issues on GitHub.

https://github.com/daar/GLPT/releases 

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: GLPT v0.1.1 released

Ingemar Ragnemalm

Any work on OpenGL is of interest to me. I am working with it every day,
have written two course books, a GLUT replacement and numerous demos,
most in C though (because my students don't learn Pascal any more).

Two things come to mind:

Yet another API for GUI-OpenGL glue? I would suggest that the closer to
an existing API (i.e. GLUT) the better. You are fairly close now so
maybe making it a GLUT replacement is just a matter of renaming?

All your demos are old-style. I can't even see a single shader anywhere.
I think you should use modern OpenGL more. For instance, I have made a
modern version of the dear old Gears demo:

http://computer-graphics.se/demopage/glut-gears.html

Not converted to C yet, but it is converted to modern OpenGL. I also
have a bunch of other demos that exist in FPC versions that you can have.

/Ingemar

Den 2018-10-09 kl. 00:46, Darius Blaszyk wrote:
> Hi all,
>
> I just released the first complete version of GLPT. Thanks to Ryan Joseph GLPT now supports Linux, MacOSX and Windows. Anyone interested in the project is invited to test, use, discuss and code. Please submit found or proposed issues on GitHub.
>
> https://github.com/daar/GLPT/releases 
>
> 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: GLPT v0.1.1 released

Darius Blaszyk-2
On Tue, Oct 9, 2018 at 7:26 AM Ingemar Ragnemalm <[hidden email]> wrote:
 
Yet another API for GUI-OpenGL glue? I would suggest that the closer to
an existing API (i.e. GLUT) the better. You are fairly close now so
maybe making it a GLUT replacement is just a matter of renaming?

True, GLPT is close to GLUT, but also to GLFW. I am not trying to create an emulator of any of the two, but rather create something that works perfectly for FPC instead. It should be relatively easy to create a wrapper unit though for GLUT and GLFW users. The same for creating a dynamic library for C users. :)
 
All your demos are old-style. I can't even see a single shader anywhere.
I think you should use modern OpenGL more. For instance, I have made a
modern version of the dear old Gears demo:

http://computer-graphics.se/demopage/glut-gears.html


Great! Can I use it for GLPT? 

Not converted to C yet, but it is converted to modern OpenGL. I also
have a bunch of other demos that exist in FPC versions that you can have.

Please share anything you can or are willing to. I need use cases to test the library and help new users to get started..

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: GLPT v0.1.1 released

Ryan Joseph
In reply to this post by Ingemar Ragnemalm


> On Oct 9, 2018, at 12:19 PM, Ingemar Ragnemalm <[hidden email]> wrote:
>
> All your demos are old-style. I can't even see a single shader anywhere. I think you should use modern OpenGL more. For instance, I have made a modern version of the dear old Gears demo:

There’s not even a way to switch the OpenGL version yet so the project is effectively not ready for use (it’s stuck on 2.1 on OS X for example).

I suggest he just adds a record to the parameters when creating a window for the simplest solution. SDL uses a constants and setter/getter functions but a simple record is better.

type
  GLPT_Context = record
    doubleBuffer: boolean;
    colorSize: byte;
    depthSize: byte;
    stencilSize: byte;
    profile: byte;
    minorVersion: byte;
    majorVersion: byte;
  end;


Regards,
        Ryan Joseph

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

Re: GLPT v0.1.1 released

Darius Blaszyk-2
Setting the OpenGl version is on top of my list. I 'm no expert but I will make the changes accordingly, counting on feedback from you all.

Rgds, Darius

On Wed, Oct 10, 2018 at 6:08 AM Ryan Joseph <[hidden email]> wrote:


> On Oct 9, 2018, at 12:19 PM, Ingemar Ragnemalm <[hidden email]> wrote:
>
> All your demos are old-style. I can't even see a single shader anywhere. I think you should use modern OpenGL more. For instance, I have made a modern version of the dear old Gears demo:

There’s not even a way to switch the OpenGL version yet so the project is effectively not ready for use (it’s stuck on 2.1 on OS X for example).

I suggest he just adds a record to the parameters when creating a window for the simplest solution. SDL uses a constants and setter/getter functions but a simple record is better.

type
  GLPT_Context = record
    doubleBuffer: boolean;
    colorSize: byte;
    depthSize: byte;
    stencilSize: byte;
    profile: byte;
    minorVersion: byte;
    majorVersion: byte;
  end;


Regards,
        Ryan Joseph

_______________________________________________
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: GLPT v0.1.1 released

Darius Blaszyk-2
In reply to this post by Darius Blaszyk-2
I created a new branch called GL-version. Accepting pull requests! 😉 



Verzonden vanaf mijn Samsung-apparaat


-------- Oorspronkelijk bericht --------
Van: Ryan Joseph <[hidden email]>
Datum: 10-10-18 05:23 (GMT+01:00)
Aan: FPC-Pascal users discussions <[hidden email]>
Onderwerp: Re: [fpc-pascal] GLPT v0.1.1 released



> On Oct 9, 2018, at 12:19 PM, Ingemar Ragnemalm <[hidden email]> wrote:
>
> All your demos are old-style. I can't even see a single shader anywhere. I think you should use modern OpenGL more. For instance, I have made a modern version of the dear old Gears demo:

There’s not even a way to switch the OpenGL version yet so the project is effectively not ready for use (it’s stuck on 2.1 on OS X for example).

I suggest he just adds a record to the parameters when creating a window for the simplest solution. SDL uses a constants and setter/getter functions but a simple record is better.

type
  GLPT_Context = record
    doubleBuffer: boolean;
    colorSize: byte;
    depthSize: byte;
    stencilSize: byte;
    profile: byte;
    minorVersion: byte;
    majorVersion: byte;
  end;


Regards,
Ryan Joseph

_______________________________________________
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: GLPT v0.1.1 released

Ryan Joseph


> On Oct 10, 2018, at 2:35 PM, dhkblaszyk <[hidden email]> wrote:
>
> I created a new branch called GL-version. Accepting pull requests! 😉
>

What do you think about simply providing a record with context options which is a param to GLPT_CreateWindow and stored in GLPTWindow? That’s by far the easiest solution and totally adequate.

Regards,
        Ryan Joseph

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

Re: GLPT v0.1.1 released

Darius Blaszyk-2
That a good idea Ryan. The only thing is that we should think about providing some sort of a fallback when the record is not setup entirely or incompatible settings are used.  

Op wo 10 okt. 2018 10:44 schreef Ryan Joseph <[hidden email]>:


> On Oct 10, 2018, at 2:35 PM, dhkblaszyk <[hidden email]> wrote:
>
> I created a new branch called GL-version. Accepting pull requests! 😉
>

What do you think about simply providing a record with context options which is a param to GLPT_CreateWindow and stored in GLPTWindow? That’s by far the easiest solution and totally adequate.

Regards,
        Ryan Joseph

_______________________________________________
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: GLPT v0.1.1 released

Anthony Walter-3
A fallback should not be created if the initialization or requested context type could not be created. It should just fail with a reason, then allow the programmer to decide what or even if there should be a fallback.

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

Re: GLPT v0.1.1 released

Darius Blaszyk-2


Op wo 10 okt. 2018 13:41 schreef Anthony Walter <[hidden email]>:
A fallback should not be created if the initialization or requested context type could not be created. It should just fail with a reason, then allow the programmer to decide what or even if there should be a fallback.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

That's a more than acceptabele solution!

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: GLPT v0.1.1 released

Darius Blaszyk-2
I committed today the generic code for setting up a specific GL version and additional parameters. What remains now is implementing the platforms. Anyone interested in helping out is welcome! I will start with GDI over the coming days. The Linux and Mac implementations will hopefully follow soon with help from the community as well as a proper test to ensure the uniform working over all platforms.

On Wed, Oct 10, 2018 at 2:07 PM Darius Blaszyk <[hidden email]> wrote:


Op wo 10 okt. 2018 13:41 schreef Anthony Walter <[hidden email]>:
A fallback should not be created if the initialization or requested context type could not be created. It should just fail with a reason, then allow the programmer to decide what or even if there should be a fallback.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

That's a more than acceptabele solution!

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: GLPT v0.1.1 released

Ryan Joseph


> On Oct 11, 2018, at 4:41 AM, Darius Blaszyk <[hidden email]> wrote:
>
> I committed today the generic code for setting up a specific GL version and additional parameters. What remains now is implementing the platforms. Anyone interested in helping out is welcome! I will start with GDI over the coming days. The Linux and Mac implementations will hopefully follow soon with help from the community as well as a proper test to ensure the uniform working over all platforms.

I’m not very good with Git yet so I need some help. Am I supposed to fork the new branch you made or copy the changes over to my existing forked branch and send a pull request from there?

Regards,
        Ryan Joseph

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

Re: GLPT v0.1.1 released

Darius Blaszyk-2
Hi Ryan,

You can switch to the new branch. See here how to do it: https://backlog.com/git-tutorial/branching/switch-branch/

Not sure though if you need to stash your local changes first to prevent losing them.

Rgds, Darius

On Thu, Oct 11, 2018 at 4:08 AM Ryan Joseph <[hidden email]> wrote:


> On Oct 11, 2018, at 4:41 AM, Darius Blaszyk <[hidden email]> wrote:
>
> I committed today the generic code for setting up a specific GL version and additional parameters. What remains now is implementing the platforms. Anyone interested in helping out is welcome! I will start with GDI over the coming days. The Linux and Mac implementations will hopefully follow soon with help from the community as well as a proper test to ensure the uniform working over all platforms.

I’m not very good with Git yet so I need some help. Am I supposed to fork the new branch you made or copy the changes over to my existing forked branch and send a pull request from there?

Regards,
        Ryan Joseph

_______________________________________________
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: GLPT v0.1.1 released

Anthony Walter-3
I haven't tried your package yet since I really don't want to boot into Windows, but I looked at your source code in the git repository.

Off the top of my head here are just a  few questions or suggestions you need to implement to make it useful:

1) I don't see any code to enumerate the supported screen resolutions
2) I don't see any code to toggle a window exclusive mode
3) I don't see any code to abstract loading OpenGL or extensions
  3a) You should provide a function to return either the OpenGL library name based on the Context requested, or a handle to the library so that GetProcAddress can be called
  3b) You should provide a platform independent function to load extensions by name
4) Your get time function is incredibly inaccurate. You should be using QueryPerformanceCounter on Windows and clock_gettime on Linux and Mac.

function GetTime should look something like this:

var
  BaseTime: Double = 0;

{$ifdef windows}
function GetTime: Double;
var
  Resolution, Counter: Int64;
begin
  QueryPerformanceFrequency(Value);
  Resolution := Resolution div 1000;
  QueryPerformanceCounter(Counter);
  Result := Counter / Resolution / 1000;
  if BaseTime = 0 then
    BaseTime := Result;
  Result := Result - BaseTime;    
end;
{$else}
function GetTime: Double;
const
  CLOCK_MONOTONIC = 1;
  Nanosecond = 1 / 1000000000;
var
  T: TTimeSpec;
begin
  clock_gettime(CLOCK_MONOTONIC, @T);
  Result := T.tv_sec + T.tv_nsec * Nanosecond;
  if BaseTime = 0 then
    BaseTime := Result;
  Result := Result - BaseTime;    
end;
{$endif}

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

Re: GLPT v0.1.1 released

Ryan Joseph


> On Oct 11, 2018, at 9:17 PM, Anthony Walter <[hidden email]> wrote:
>
> 1) I don't see any code to enumerate the supported screen resolutions

What do mean exactly? The API just returns a window with a OpenGL context. Resolution is the job of the user to define per their needs.

> 2) I don't see any code to toggle a window exclusive mode

Yeah it needs an option for full screen windows no doubt (I think that’s what you mean).

> 3) I don't see any code to abstract loading OpenGL or extensions
>   3a) You should provide a function to return either the OpenGL library name based on the Context requested, or a handle to the library so that GetProcAddress can be called
>   3b) You should provide a platform independent function to load extensions by name

I think the GL and GLExt have this functionality but I’m not sure if makes sense to call it for the user. That’s what I do with SDL.

> 4) Your get time function is incredibly inaccurate. You should be using QueryPerformanceCounter on Windows and clock_gettime on Linux and Mac.

I used NSDate class on Mac (Cocoa) but I’m not sure if it’s less accurate than your method.

Regards,
        Ryan Joseph

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

Re: GLPT v0.1.1 released

Anthony Walter-3
Ryan,

1&2:

Typically what happens is the programmer can enumerate the supported exclusive (full screen and dedicated to a graphics context) resolution modes. The available resolution modes is dependent on their monitor, video driver, and operating system. Each mode defines a width and height in pixels, the color depth, and refresh rate. When the programmer creates a window they need some way to find, or enumerate, these modes, and they also need a way to switch the window and context to fit one of these modes. These are all things that should be supported by the underlying graphics toolkit. That is, the toolkit should allow the programmer to find out what modes exists on the end users computer, and pick one of those modes possibly before creating the window and context.

3: 

The OpenGL API functions such as glGenBuffers, or glUseProgram are provided by either an open source community, or from the operating system, or from the hardware manufacturer driver. You cannot statically link these functions to a so (shared object) or dll (dynamic link library) at compile time, because based on the users configuration they reside in several possible locations. For example on Linux when an OpenGL ES 2 context is needed the OpenGL functions must come from libGLESv2.so located in in a vendor specific lib folder created by nVidia. For a core context the libGL.so is a different name and located in a different folder. It is the job of the toolkit to determine based on the request context type which OpenGL library should be loaded. That library should then be passed back to the programmer so that he can link to the correct OpenGL API for the context he requested.

Each platform Windows, Linux, and Mac have their own APIs to make it easier to find the correct OpenGL library. Windows has wgl, Linux has egl, and mac has something else. Your toolkit should at least cover the differences in wgl, egl, and the Mac API so that programmers don't need to add their own wgl or egl code.

The Free Pascal LoadLibrary and FetProcAddress should be sufficient enough to load the appropriate OpenGL function if you can tell then either the path to the OpenGL library, or more realistically the handle to the already OpenGL library already loaded by you.

Regarding extensions, each platform and library has their own implementation of how to get the address of an OpenGL extension. On Windows you can use wglGetProcAddress, while on Linux you would use wglGetProcAdress. Your toolkit should provide an abstraction so that it's doesn't matter which platform you are on and the extension loading is handled the same.

4:

In your source code for Windows you are using GetTickCount to return the time. See this stack overflow answer to see why that's a bad thing.


The code I provided you should give high resolution timing on all platforms. Use it if you want, but please don't rely on GetTickCount for time on Windows.

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

Re: GLPT v0.1.1 released

Graeme Geldenhuys-6
In reply to this post by Darius Blaszyk-2
On 11/10/18 05:39, Darius Blaszyk wrote:
> Not sure though if you need to stash your local changes first to prevent
> losing them.

For contribution to a project I ALWAYS recommend they work in a separate
branch. There are many benefits to that from both side (per writing code
and person merging changes upstream).

Some benefits:
  * They can do a pull from the upstream repository and it doesn't
affect there branch - no merge conflicts, no stashes required.
  * Developer can the review upstream changes as and when needed. When
they have the time, they can rebase or merge upstream changes into there
branch. At a convenient time.
  * Seeing what has changes between branches is supper simple - branches
are done correctly in Git, and makes work very easy.
  * Super simple one line command to generate a set of patches (similar
to previous point) and email those, in case the developer doesn't have a
publicly accessible repository (eg: private, Github etc).

The list goes on, but the above is the major points.

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: GLPT v0.1.1 released

Ryan Joseph
In reply to this post by Anthony Walter-3


> On Oct 11, 2018, at 11:39 PM, Anthony Walter <[hidden email]> wrote:
>
> Ryan,
>
> 1&2:
>
> Typically what happens is the programmer can enumerate the supported exclusive (full screen and dedicated to a graphics context) resolution modes. The available resolution modes is dependent on their monitor, video driver, and operating system. Each mode defines a width and height in pixels, the color depth, and refresh rate. When the programmer creates a window they need some way to find, or enumerate, these modes, and they also need a way to switch the window and context to fit one of these modes. These are all things that should be supported by the underlying graphics toolkit. That is, the toolkit should allow the programmer to find out what modes exists on the end users computer, and pick one of those modes possibly before creating the window and context.

Got it. Yeah there should be a method to return resolutions for the device. I’m just helping him with the Mac stuff but it’s his project so not sure if this on the list (the API is meant to be small as I understand it). SDL has a pretty comprehensive list of device functions so that leads me to believe its important.

>
> 3:
>

I’m not sure if he wants this to be part of the API. I use SDL and I’ve just used Load_GL_VERSION_XXX calls that the FPC RTL provides which works.

Just looked and I see SDL has some functions that you describe. I think the FPC RTL is cross platform also though so this may not be needed for us.

function SDL_GL_LoadLibrary(path: SDL_Char): LongInt; cdecl; external;
function SDL_GL_GetProcAddress(proc: SDL_Char): Pointer; cdecl; external;
procedure SDL_GL_UnloadLibrary; cdecl; external;


>
> 4:
>
> In your source code for Windows you are using GetTickCount to return the time. See this stack overflow answer to see why that's a bad thing.
>
> https://stackoverflow.com/questions/24009263/why-queryperformancecounter-and-gettickcount-does-not-keep-in-pace

Yeah TickCount is probably too low-res. NSDate is millisecond precision I think.

Regards,
        Ryan Joseph

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

Re: GLPT v0.1.1 released

Anthony Walter-3
Regarding the RTL OpenGL unit working, that is because it assumes the CORE profile is the only OpenGL library. If you request an ES profile, those libraries are no longer valid.

In SDL:

SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);

Which may link to any of:

libGLESv2.so
libGLESv1_CM.so
libGL.so

It's up to the toolkit to choose the correct OpenGL library based on the context type requested. The is what SDL_GL_GetProcAddress is abstracting.


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