FreeGlut - What do you developers think?

[Pete]

I was reading up on it a bit, since KernelPanic brought it up in another thread. Apparently FreeGlut is compatible with Windows, Apple and Linux. I see it handles key modifies like Ctrl, but I can't find a list of the combos it supports. This could mean it supports all, which sadly GLUT in OpenGL does not. So have any developers looked into this as an alternative? I'm keeping in mind FreeGlut would need to include all GLUT functions. To that end, AI says:

Yes, freeglut is designed to be a full replacement for the original OpenGL Utility Toolkit (GLUT) and does everything that GLUT does, with some enhancements and improvements. It is also more stable and has fewer bugs than the original GLUT. 

Would a change be in order, or would licensing be an issue?

Pete

[SMcNeill]

Isn't FreeGLUT what we already have under the hood which is buggy?

Plans are currently underway for a swapping out of GLUT completely.  It's just one of them things that's woven into a lot of crapola and has to be rooted out carefully before it breaks a lot of crap trying to replace it. 

[Pete]

Isn't FreeGLUT what we already have under the hood which is buggy?

Plans are currently underway for a swapping out of GLUT completely.  It's just one of them things that's woven into a lot of crapola and has to be rooted out carefully before it breaks a lot of crap trying to replace it. 

I'm not sure. Apparently there is Glut (OpenGL) and FreeGlut a SourceFordge project. I thought we have the former.

A Stack Overflow Reply:
The original implementation of GLUT was released under a license that prohibited modification. freeglut is a reimplementation of the GLUT API under a MIT license. There has been more development on freeglut and it has extensions to the API as well, but in my experience, there are some quirks of older versions of GLUT that aren't replicated in freeglut.

Breaking things is always a difficult assessment to make. I think I still have one program that runs perfectly fine in SDL but shows a minor graphics bleed in whatever it is we have now. I remember the same thing happened to TheBob's White Cake Recipe. 

I recall Rob needed to use the Android NDK wrapper to attempt running QB4 on Android devices. That sounds like plain old GLUT to me. Freeglut is supposed to be more Android adaptable but that feature is apparently in its early development.

Anyway, if we don't already use it and Freeglut is to Glut what QB64 is to QB45, it might be worth a look.

Pete

[SMcNeill]

\internal\c\parts\core\freeglut    <-- There's FREEGLUT already in use.

We needs to replace it all with GLFW or RGFW.

Both have been looked at, and @a740g has been working on swapping in RGFW in his spare time.  It's just a lot of junk to yank out and replace, so it's the type of thing that takes patience. 

[Pete]

It's a good thing my name's not Shane, or that damn Pete would have replied....

Shane, you ignorant glut! (From the good ol' days when SNL didn't completely suck).

Well if we were going to stick with it, I'd get a rapport started with the developer(s) of that project, but since we are slated to ditch it in the future, that won't be on my to do list. I guess we got what we didn't pay for. Hey, how about we invent FeeGlut?  

Pete

[SMcNeill]

Asked: GLUT doesn't respond to ``CTRL + number`` keypresses. Did FreeGlut ever fix that issue?


Short answer: No — FreeGLUT never fully fixed the classic “CTRL + number doesn’t generate a keyboard callback” problem. The limitation still exists today because it originates in how operating systems deliver key events, not in GLUT itself.

Why the issue persists
1. The root cause is OS‑level behavior
On both Windows and Linux/X11, pressing CTRL + number often produces no printable character and also does not generate a GLUT “special key” event.
The OS simply does not send a normal keypress message for those combinations, so GLUT/FreeGLUT never receives anything to translate.

This is why the original GLUT had the problem, and FreeGLUT inherited it.

2. FreeGLUT’s maintainers acknowledged the limitation
Developer discussions and bug threads show that FreeGLUT’s input layer depends on the OS event stream. Since the OS does not deliver a usable keycode for CTRL+number, FreeGLUT cannot synthesize one without breaking compatibility.

3. No patch was ever merged to “fix” it
FreeGLUT has improved modifier handling over the years, but CTRL+number still does not generate a glutKeyboardFunc or glutSpecialFunc callback.
The issue is not listed as resolved in FreeGLUT’s bug tracker, and no release notes mention a fix.

[Kernelpanic]

And what about this? Could that help?

[Text]
glutKeyboardFunc sets a callback function void func(unsigned char key, int x, int y) to handle ASCII keystrokes in GLUT. When a key is pressed, it passes the character (key) and mouse coordinates (x, y). This handles letters, numbers, and symbols, but not special keys like F1 or arrow keys.

Key Details for glutKeyboardFunc:
Signature: void glutKeyboardFunc(void (*func)(unsigned char key, int x, int y)).
Usage: Used to detect key presses such as 'q' for quit or number keys for input.

Callback Parameters:
unsigned char key: The ASCII character of the pressed key.
int x, int y: Mouse position relative to the window when the key was pressed.

Limitations: Does not handle special keys (use glutSpecialFunc instead). Modifiers (Shift/Ctrl) can be checked with glutGetModifiers.
[/Text]

[Unseen Machine]

I avoid it like the plague! It sucks! (In my view anyway!)

John

[Pete]

And what about this? Could that help?

[Text]
glutKeyboardFunc sets a callback function void func(unsigned char key, int x, int y) to handle ASCII keystrokes in GLUT. When a key is pressed, it passes the character (key) and mouse coordinates (x, y). This handles letters, numbers, and symbols, but not special keys like F1 or arrow keys.

Key Details for glutKeyboardFunc:
Signature: void glutKeyboardFunc(void (*func)(unsigned char key, int x, int y)).
Usage: Used to detect key presses such as 'q' for quit or number keys for input.

Callback Parameters:
unsigned char key: The ASCII character of the pressed key.
int x, int y: Mouse position relative to the window when the key was pressed.

Limitations: Does not handle special keys (use glutSpecialFunc instead). Modifiers (Shift/Ctrl) can be checked with glutGetModifiers.
[/Text]

This depends on how the keys are polled. We can poll the Ctrl key in QB64 via freeglut, but while it's held down the plus sign key is no longer polled at its independent value. I wish they thought of that, and made a way to poll both separately. If they did, we have missed taking advantage of it.

For instance: To detect the Ctrl key and the Plus key in Win32 API, you can check for the virtual-key codes VK_CONTROL (0x11) for the Ctrl key and VK_OEM_PLUS (0xBB) for the Plus key in your message handling function. Use the WM_KEYDOWN message to determine when these keys are pressed together.

I prefer this independent system, instead of changing the values for the key combinations. As long as we had a separate way of coding for this, there would be no breaking compatibility.

Pete

[Unseen Machine]

Code: (Select All)

' Declare the Windows API function

DECLARE LIBRARY

  FUNCTION GetAsyncKeyState% (BYVAL vKey AS INTEGER)

END DECLARE



' Windows Virtual-Key Constants

CONST VK_CONTROL = &H11

CONST VK_OEM_PLUS = &HBB ' The + / = key

CONST VK_OEM_MINUS = &HBD ' The - / _ key

CONST VK_ESCAPE = &H1B



DIM counter AS INTEGER: counter = 0

DIM plusPressed AS INTEGER: plusPressed = 0

DIM minusPressed AS INTEGER: minusPressed = 0



PRINT "Counter: 0"

PRINT "Use Ctrl + [+] to increase and Ctrl + [-] to decrease."



DO

  ' Check if Ctrl is held down

  IF GetAsyncKeyState%(VK_CONTROL) AND &H8000 THEN



    ' Handle Plus (+) Key with debouncing (only trigger once per press)

    IF GetAsyncKeyState%(VK_OEM_PLUS) AND &H8000 THEN

      IF plusPressed = 0 THEN

        counter = counter + 1

        GOSUB RefreshDisplay

        plusPressed = 1

      END IF

    ELSE

      plusPressed = 0

    END IF



    ' Handle Minus (-) Key with debouncing

    IF GetAsyncKeyState%(VK_OEM_MINUS) AND &H8000 THEN

      IF minusPressed = 0 THEN

        counter = counter - 1

        GOSUB RefreshDisplay

        minusPressed = 1

      END IF

    ELSE

      minusPressed = 0

    END IF



  END IF



  ' Exit if ESC is pressed

  IF GetAsyncKeyState%(VK_ESCAPE) AND &H8000 THEN EXIT DO



  _LIMIT 60

LOOP

END



RefreshDisplay:

CLS

PRINT "Current Counter:"; counter

PRINT "Use Ctrl + [+] to increase and Ctrl + [-] to decrease."

RETURN

Should work under wine on linux...hope it helps

Me