daar/glpt

GLPT :: OpenGL Pascal Toolkit. A multi-platform library for OpenGL and OpenGL ES

glpt's Issues

GLPT_Context Question

What is the GLPT_Context used for?

GLPT/GLPT.pas

Lines 619 to 627 in a6d0e57

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

Is the majorVersion and minorVersion supposed to control what OpenGL version is loaded?
It doesn't look like any of these properties are used in any platform specific code when generating the actual OpenGL context.

For example X11 just sets dpy and passes that around.

GLPT/GLPT_X11.inc

Line 332 in a6d0e57

win^.dpy := XOpenDisplay(nil);

I attempted to create my own Context and pass it to GLPT_CreateWindow, but it didn't seem to load any opengl versions based on what I set majorVersion or minorVersion.

I ended up having to do the following otherwise anything from GLExt (e.g. glCreateShader) appears to throw an Access Violation error:

    if not GLPT_Init then halt(-1);

    window := GLPT_CreateWindow(0, 0, width, height, 'Hello Triangle', GLPT_GetDefaultContext);
    if window = nil then
    begin
        GLPT_Terminate();
        halt(-1);
    end;

    window^.event_callback := @event_callback;

    //this check appears to be needed?
    if Load_GL_VERSION_3_3 = false then
    begin
        writeln(' ERROR: OpenGL 3.3 is needed. '); 
        GLPT_Terminate();
        halt(-1);
    end;

Is what I'm doing how you intend it to work?

GLPT_GetBasePath and GLPT_GetPrefPath needed?

These functions have FPC equivalents ParamStr(0) and GetAppConfigDir and GetAppConfigFile. The functions were added in revision 195b42f.

{
  Use this function to get the directory where the application was run from. 
  This is where the application data directory is.
  @return path of directory
}
function GLPT_GetBasePath: string;

{
  Use this function to get the "pref dir". This is meant to be where the application 
  can write personal files (Preferences and save games, etc.) that are specific to the application. 
  This directory is unique per user and per application.
  @param org: name of organization
  @param app: name of application
  @return path of directory
}
function GLPT_GetPrefPath (org: string; app: string): string;

Screenshot for MacOS

Can anyone with MacOS supply a screenshot of one of the example files, or of it's own project? Just make a pull request and add the image to the image folder and update the README.md file. We are now working on the GL-version branch at the moment.

Window too small on Windows 10

I'm trying to test using Windows 10 emulation on my Mac (VirtualBox) and when I run a program the window is minimized to a tiny size but looks ok if I expand to fit the screen. What's wrong?

GLPT_GetTicks needed?

This function is essentially the same as GLPT_GetTime * 1000. So do we need it?

Open discussions

Daar, there is a new feature in Github called "discussions" which you should enable so we can talk easier. I have some questions about to merge some of my changes before it gets even harder than it already is. Thanks.

interesting-but flawed code

there is a lot to cover- thats why I didnt specify much.
suggestions:

there is no exit(xyz)-
its:

return(xyz)

or
functionName:=xyz.

Im seeing this in other places. Those people have used another library override of the LCL- and they redefine the language. You dont seem to be doing that. So either this is not wirtten for FPC- or its written assuming a flawed interpreter.

2ndly- travisCL doesnt support Pascal. Why you think it will is beyond me. Id love to use it for tracing sources- but it doesnt support Pascal.

You hand off the methods to the OS specific functions. nothing wrong there.

But using GDI and X11 core is where you go wrong.

Further it seems the GL code references the old xgl libs, not the newer GL ones.
This could be the problem.

GL,GLU, Glext-

and you are rewriting GLUT/freeGLUT. Theres no need to do that.

GL is either available-
post XP,
with X11,
installed alongside Carbon- or its not.

Cocoa- OS9- isnt supported.
(You need DirectDraw calls for that OS.)
minimum supported OpenGL is for OSX 10.2.

There is no need to avoid GL calls.
win32 and Carbon parts of the API are avoiding GL calls.

x11 uses them- but only if we hook X11 functions(like the GDI)

• which is not the proper way to do things.

GL and GLU/GLUT/freeGLUT can handle window contexts for you.

Unless you are giving us threaded input- and otherwise giving us functions that GLUT isnt providing- there is no need to avoid it.

While most prefer SDL syntax for input processing- it too has a "you cannot process input while rendering in a loop" bug. freeGLUT has the same issue. I doubt youve fixed this.

seems to me like may know SDL-
(and its a good start) but you may not know the "GL basics".

Id like to see this go further.