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

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

AM Ingemar Ragnemalm 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. :)

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

On Oct 9, 2018, at 12:19 PM, Ingemar Ragnemalm 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

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

I created a new branch called GL-version. Accepting pull requests! 😉 

Verzonden vanaf mijn Samsung-apparaat

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

On Oct 9, 2018, at 12:19 PM, Ingemar Ragnemalm 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

On Oct 10, 2018, at 2:35 PM, dhkblaszyk 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

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 :

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.

Op wo 10 okt. 2018 13:41 schreef Anthony Walter :

That's a more than acceptabele solution!

Rgds Darius

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 Oct 11, 2018, at 4:41 AM, Darius Blaszyk 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

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

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}

On Oct 11, 2018, at 9:17 PM, Anthony Walter 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

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.

https://stackoverflow.com/questions/24009263/why-queryperformancecounter-and-gettickcount-does-not-keep-in-pace

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.

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

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;

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

Regards,
Ryan Joseph

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.