saschawillems/dglopengl

Delphi / Pascal OpenGL header translation (including WGL and GLX)

💬 About me

I've been an active Open Source developer for more than 25 years now (even before that term was actually coined). At ☀️ day I'm a software development team lead in the automotive area, and at 🌑 night (and during 🏖️ weekends) I contribute to Open Source projects related to 3D realtime graphics using open standards from Khronos.

• 🏠 My personal home page
• 🗂️ My open community driven GPU hardware databases
• 🔭 Khronos repositories
• 👋🏻 For Vulkan related help you can find me in the Vulkan Discord and the Subreddit

dglopengl's Issues

TRect not part of default fpc

Please add this definition again. TRect is not defined in fpc but instead only in the RTL (for example lazarus / windows/...) and thus not having these lines breaks building for various command-line targets. (this would effectively revert your last two commits)

{$IFDEF FPC}
TRect = packed record
Left, Top, Right, Bottom: Longint;
end;
{$ENDIF}

Read_GL_ARB_bindless_texture

Hi,
In the Read_GL_ARB_bindless_texture procedure all proc names begin with 't' like:
glGetTextureHandleARB := dglGetProcAddress('TglGetTextureHandleARB');
So the addresses of these functions are not resolved.

There is also no call for Read_GL_ARB_bindless_texture procedure in the ReadExtensions proc.

Thanks for the translation!

Define TRect only for FPC-Versions lower 20602

If compiled from Free Pascal, the header defines a TRect datatype that was initially missing from FPC. Newer versions of FPC implement TRect, causing type collisions.

The definition needs to depend on the FPC compiler version (<20602)

ReadCoreVersion fails on OS X when compiling with FPC 3.0.0

We, the UltraStar Deluxe team, are currently preparing a new release and am now trying to get the SDL2 based game to work on OS X. Sadly, after switching to dglOpenGL, executing the game fails on Mac OS X el capitain in dglOpelGL.pas procedure ReadCoreVersion line 19615 AnsiBuffer := glGetString(GL_VERSION);

Compiling works without any problem and dglOpenGL works without any problem on Linux and Windows based systems.
Any idea what could cause this issue?

We call the function from https://github.com/UltraStar-Deluxe/USDX/blob/master/src/base/UGraphic.pas#L681
Thanks in advance!

Create ES context?

I want to write a cross-platform app using Delphi Windows/Android cross compile feature.
I would like to create a ES/EGL context and limit myself to e.g. ES 3.2 API subset
Is it possible with dgl?

support Android?

Are there plans to support Android?

Allow libGL to be loaded and function addresses to be resolved by SDL

SDL allows to create a GL context for a video device and will resolve GL function addresses for the GL library it uses. It is an error prone step to then try to load libGL again, not knowing the correct path.
Over at UltraStar-Deluxe I proposed a commit s09bQ5/USDX@c4e1908 that optionally uses SDL to handle libGL, but there are fears that modifying dglOpenGL will complicate making an update. Is there any chance of getting something like this into one of the next dglOpenGL releases?

For SDL in Pascal we are using this.

GPU_DEVICE should be in a conditional

On a platform other than windows, the GPU_DEVICE structure should be in a conditional, or restore the TRect type which is also a windows specific thing. Afaik, I don't think GPU_DEVICE is used outside of windows, so no need to restore the TRect conditional.