alexcharlton / cl-glfw3

Common Lisp bindings to GLFW version 3.x

cl-glfw3

Bindings for the GLFW library, version 3.x, for Common Lisp.

These bindings have been enhanced with several conveniences, as described in cl-glfw3.lisp.

Direct bindings to all GLFW functions can be found in the system %glfw glfw-bindings.lisp.

Installing

cl-glfw3 is Quicklisp installable! Just type:

(ql:quickload :cl-glfw3)

Running the resulting system requires GLFW version 3.x and libffi to be installed on your computer.

OSX

• brew install glfw libffi

Ubuntu/Debian

• sudo apt-get install libglfw3 libffi-dev

Examples

Examples can be found in the examples directory.

The examples rely on cl-opengl (which Quicklisp will take care of) and require that OpenGL be installed on your computer.

These can be loaded through Quicklisp with:

(ql:quickload :cl-glfw3-examples)

(cl-glfw3-examples:events-example)
(cl-glfw3-examples:basic-window-example)
(cl-glfw3-examples:particles-basic-example)
(cl-glfw3-examples:fragment-shader-example)

Documentation

The best place to find documentation for GLFW3 is their official site.

Stability

At the moment these bindings are largely untested, aside from what can be seen in the examples directory. Contributions are most welcome!

cl-glfw3's Issues

def-key-callback mod-keys, et al

The body of the def-key-callback macro does not unquote the mod-keys parameter to defcallback.

One of the monitor functions (I think it was get-window-monitor) has an empty let followed by an unless that uses the variables declared in the let...it just needs a parenthesis moved.

glfw:get-clipboard-string has what looks like a copy/paste error so it's calling set-clipboard-string. This was erroring out for me because it had the wrong parameter count.

Plus there are a few compiler warnings in a very recent CCL about unused parameters.

I'll have a pull request that fixes these shortly.

load alternately name shared libary?

(define-foreign-library (glfw)
     (:darwin (:or
               ; homebrew naming
               "libglfw3.1.dylib" "libglfw3.dylib"
               ; cmake build naming
               "libglfw.3.1.dylib" "libglfw.3.dylib"))
     (:unix (:or "libglfw.so.3.1" "libglfw.so.3"))
     (:windows "glfw3.dll")
     (t (:or (:default "libglfw3") (:default "libglfw"))))

(use-foreign-library glfw)

If the glfw library has a different name, then it won't load.
I'm trying to load glfw-blob by borodust, which is named like libglfw.[dll,dylib,so].bodged
Would you accept a pull request that customizes this behavior?

WITH-CONTEXT macro not changing the current context.

Here is the definition of WITH-CONTEXT:

(defmacro with-context (window &body body)
  `(let* ((*window* ,window))
     ,@body))

The special variable *window* is changed but not the current context of the window, and the name of the macro, imo, suggest that the current context of the window is also changed. I think this can be confusing.

Mac Issues

Hi, I'm having a problem getting up and running on the mac with your library and I'd love to get to the bottom of this if possible as I'm keen to port the superbible 7 examples over as a learning exercise. I'm not a l33t lisper as I'm coming back to the language after a 20 year hiatus.

In sbcl I see the following floating-point-overflow error which looks pretty much the same as I've encountered running some glut examples.

• (ql:quickload "cl-glfw3-examples")
  To load "cl-glfw3-examples":
  Load 1 ASDF system:
  cl-glfw3-examples
  ; Loading "cl-glfw3-examples"
  ............
  ("cl-glfw3-examples")
• (cl-glfw3-examples:basic-window-example)

debugger invoked on a FLOATING-POINT-OVERFLOW in thread

<THREAD "main thread" RUNNING {1002C74733}>:

arithmetic error FLOATING-POINT-OVERFLOW signalled

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.

("bogus stack frame")
0]

At this point I have to exit sbcl to close the exec icon that appears in the dock. I can we the window rendered correctly however.

In ccl64 I get a different issue:

? (ql:quickload "cl-glfw3-examples")
To load "cl-glfw3-examples":
Load 1 ASDF system:
cl-glfw3-examples
; Loading "cl-glfw3-examples"

("cl-glfw3-examples")
? (cl-glfw3-examples:basic-window-example)
2015-10-08 13:14:05.733 dx86cl64[15465:315830] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-1154/Misc.subproj/NSUndoManager.m:340
2015-10-08 13:14:05.734 dx86cl64[15465:315830] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.
2015-10-08 13:14:05.735 dx86cl64[15465:315830](0 CoreFoundation 0x00007fff916dd03c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff9726076e objc_exception_throw + 43
2 CoreFoundation 0x00007fff916dce1a +[NSException raise:format:arguments:] + 106
3 Foundation 0x00007fff9759299b -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 195
4 Foundation 0x00007fff9751464f +[NSUndoManager%28NSPrivate%29 _endTopLevelGroupings] + 156
5 AppKit 0x00007fff8ba6cb95 -[NSApplication run] + 756
6 libglfw3.dylib 0x00000000000dc85c _glfwPlatformCreateWindow + 1410
7 libglfw3.dylib 0x00000000000d920f glfwCreateWindow + 582
8 dx86cl64 0x000000000001b693 ffcall_return + 0)
2015-10-08 13:14:05.735 dx86cl64[15465:315830] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-1154/Misc.subproj/NSUndoManager.m:340
Unhandled exception 10 at 0x0, context->regs at #xb0299bd0
Exception occurred while executing foreign code
received signal 10; faulting address: 0x0
? for help
[15465] Clozure CL kernel debugger:

I'm stumped as to what I need to do to progress - do you have any ideas? I see that you have some darwin conditional statements in the code so assume you've managed to get something up and running in the past, is that correct?

Thanks in advance for help,

Colin

cffi-libffi issue on arm (Nvidia Tegra K1)

Edit: I've narrowed the problem down to just set-gamma-ramp. I'm seeing if I can fix it to not use a cffi-libffi dependent feature of calling structures by value.

---

Hi there. I have good news and bad news. The bad news is that there seems to be an issue with cffi-libffi on arm. (I'm running an Nvidia Tegra K1 with Ubuntu.) The good news is, only four one function depend on cffi-libffi. They are:

• get-video-modes
• get-video-mode
• get-gamma-ramp
• set-gamma-ramp

I have forked your repo and commented out these functions (as they don't seem to be critical): https://github.com/tjklemz/cl-glfw3/tree/remove-cffi-libffi

I then cloned that to local-projects in the quicklisp directory and re-loaded. It works great! I'm using Clozure CL.

Is there a way we can modify those four functions to not use the cffi-libffi dependency? It appears to have something to do with the :struct keyword. I'm not the best with cffi, but I may take a whack at it later tomorrow. I figured I would document the problem here, though.

Window just hangs when I close it

I'm on a Mac OS X

So here's a script that I'm runnning:

(ql:quickload :cl-glfw3)
(ql:quickload :cl-opengl)
(ql:quickload :trivial-main-thread)

(glfw:def-key-callback quit-on-escape (window key scancode action mod-keys)
  (declare (ignore window scancode mod-keys))
  (when (and (eq key :escape) (eq action :press))
    (glfw:set-window-should-close)))

(defun render ()
  (gl:clear :color-buffer)
  (gl:with-pushed-matrix
    (gl:color 1 1 1)
    (gl:rect -25 -25 25 25)))

(defun set-viewport (width height)
  (gl:viewport 0 0 width height)
  (gl:matrix-mode :projection)
  (gl:load-identity)
  (gl:ortho -50 50 -50 50 -1 1)
  (gl:matrix-mode :modelview)
  (gl:load-identity))

(glfw:def-window-size-callback update-viewport (window w h)
  (declare (ignore window))
  (set-viewport w h))

(defun basic-window-example ()
  ;; Graphics calls on OS X must occur in the main thread
  ;; Though I have found that it works without this
  (trivial-main-thread:with-body-in-main-thread ()
    (glfw:with-init-window (:title "Window test" :width 600 :height 400)
      (setf %gl:*gl-get-proc-address* #'glfw:get-proc-address)
      (glfw:set-key-callback 'quit-on-escape)
      (glfw:set-window-size-callback 'update-viewport)
      (gl:clear-color 0 0 0 0)
      (set-viewport 600 400)
      (loop until (glfw:window-should-close-p)
            do (render)
            do (glfw:swap-buffers)
            do (glfw:poll-events)))))

It is practically a clone of the basic window example (https://github.com/AlexCharlton/cl-glfw3/blob/master/examples/basic-window.lisp) but I've namespaced functions (trying to help myself learn 😄)

When I run it in the REPL, a window loads with a white rectangle, which is great. The only problem is that when I click the close button on the window, it doesn't close. The loop ends, but the window remains open.

I've tried adding

(glfw:destroy-window)
(glfw:terminate)

after the loop terminates but still no luck.

Edit: I see now that with-init-window automatically destroys the window and terminates GLFW so there's no point adding more calls

Do you have any ideas?

This seems reminiscent of this problem: https://stackoverflow.com/q/22312630

But as far as I can tell the proposed solutions have already been done in the example

🤔

Thanks,

Luke

PS I'm finding this project greatly helpfulp in learning Common Lisp and feeling the power of setting up graphics on the fly in a REPL. Thanks!

(ql:quickload :cl-glfw3) fails on LispWorks

I'm running LispWorks Personal Edition 6.1.1 on Windows 10, and quickload is giving me the following error:

CL-USER 2 > (ql:quickload 'cl-glfw3)
To load "cl-glfw3":
  Load 1 ASDF system:
    cl-glfw3
; Loading "cl-glfw3"

Error: Unable to load any of the alternatives:
   ((:DEFAULT "libglfw3") (:DEFAULT "libglfw"))
   1 (continue) Try loading the foreign library again.
   2 Use another library instead.
   3 Try loading C:\Users\e\AppData\Local\cache\common-lisp\lwpe-6.1.1-win-x86\C\Users\e\quicklisp\dists\quicklisp\software\cl-glfw3-20170124-git\glfw-bindings.ofasl again.
   4 Give up loading C:\Users\e\AppData\Local\cache\common-lisp\lwpe-6.1.1-win-x86\C\Users\e\quicklisp\dists\quicklisp\software\cl-glfw3-20170124-git\glfw-bindings.ofasl.
   5 Try loading another file instead of C:\Users\e\AppData\Local\cache\common-lisp\lwpe-6.1.1-win-x86\C\Users\e\quicklisp\dists\quicklisp\software\cl-glfw3-20170124-git\glfw-bindings.ofasl.
   6 Recompile glfw-bindings and try loading it again
   7 Retry loading FASL for
   #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cl-glfw3" "glfw-bindings">.
   8 Continue, treating loading FASL for
   #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cl-glfw3" "glfw-bindings">
     as having been successful.
   9 Retry ASDF operation.
  10 Retry ASDF operation after resetting the configuration.
  11 (abort) Give up on "cl-glfw3"
  12 Return to level 0.
  13 Return to top loop level 0.

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.

Selecting continuation option 2 is able to correct the problem by specifying glfw's actual Windows filename:

%CL-GLFW3 3 : 1 > :c 2
Enter a new value (unevaluated): ("glfw3.dll")
Creating foreign funcallable for signature (:POINTER :POINTER :POINTER) -> :VOID
Creating foreign funcallable for signature (:POINTER) -> :POINTER
Creating foreign funcallable for signature (:POINTER :POINTER) -> :POINTER
.
Creating foreign funcallable for signature (:INT :POINTER) -> :POINTER

(CL-GLFW3)

At this point, it's at least capable of opening a window and running keyboard handlers; I haven't tried getting the graphics pipeline to work yet.

If you're trying to reproduce the issue, note that LispWorks Personal ships with an ancient version of asdf that has to be upgraded before quicklisp will work. I used the instructions here to do this.

Error when compiling def-key-callback forms

When I try to compile a def-key-callback form in SBCL with sly, it signals an error:

failed AVER:
    (MEMBER SB-C::CLAMBDA
            (SB-C::COMPONENT-LAMBDAS
             (SB-C::LAMBDA-COMPONENT SB-C::CLAMBDA)))
This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at <http://sbcl.sourceforge.net/>.
   [Condition of type SB-INT:BUG]

I can evaluate the def-key-callback form, and the callback works correctly when I run the program. It's only compiling that signals the error.

The error occurs under Linux (manjaro), SBCL v2.3.7, but doesn't occur when I compile under Windows.

GL crashes when using version 4

I am trying to run simple example and I want to use OpenGL version 4.
However, when I set :context-version-major 4 in with-window, GL crashes.
I have GLFW 3.3 installed.

Code which I'm running:

(defun main ()
  (glfw:with-init
    (glfw:with-window (:width 640 :height 480 :title "CL-GLFW3"
                       :context-version-major 4)
      (setf %gl:*gl-get-proc-address* #'glfw:get-proc-address)
      (gl:clear-color 0 0.5 1 1)
      (loop until (glfw:window-should-close-p)
            do ((lambda ()
                  (gl:clear :color-buffer)
                  (gl:color 1 1 1 1)
                  (gl:rect 0 0 1 1)))
            do (glfw:swap-buffers)
            do (glfw:poll-events)))))

Error report:

debugger invoked on a CL-OPENGL-BINDINGS:OPENGL-ERROR in thread
#<THREAD "main thread" RUNNING {10004F04C3}>:
  OpenGL signalled (1282 . INVALID-OPERATION) from COLOR-4F.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE] Continue
  1: [ABORT   ] Exit debugger, returning to top level.

(CL-OPENGL-BINDINGS:CHECK-ERROR #<unavailable argument>)
   source: (RESTART-CASE (ERROR 'OPENGL-ERROR :ERROR-CODE
                                (CONS ERROR-CODE
                                      (CFFI:FOREIGN-ENUM-KEYWORD
                                       'CL-OPENGL-BINDINGS:ENUM ERROR-CODE))
                                :ERROR-CONTEXT CONTEXT)
             (CONTINUE NIL :REPORT "Continue"))

window-hint is undefined outside of %glfw

I am producing a minimal example to repro the issue. I am on Linux and using sbcl.

(defpackage #:playground2
  (:nicknames :pg2)
  (:use #:cl #:cl-vulkan #:cl-glfw3)
  (:export :basic-example))

(in-package #:playground2)

(defun basic-example ()
  (with-init-window (:width 860 :height 600 :title "vulkan" :resizable 0 :client-api 0)
    (loop until (window-should-close-p)
       do (poll-events)
	 )))

Now basic-example won't run for me. It complains that window-hint is undefined. I had to change (window-hint :client-api 0) to (%glfw:window-hint :client-api) in with-window macro to get it working. But strangely if I remove :resizable 0 :client-api 0 in the above code, then it does not complain about undefined window-hint.

Btw, I also noticed that there is a c enum defined with window-hint name and also a function with the same name glfw-bindings.lisp. Not sure if that is related to this issue or not though.

the examples don't appear to be rendered as intended (example is provided)

Hi,

The cl-glfw3-examples seem to render quite wrong on my machine. See a
short video (56s) here:

https://youtu.be/uLWCcmp0NFM

This is on arch linux with the following specs:

CL: SBCL 2.3.4
X11: X.Org version: 21.1.8
glfw3: glfw-x11-3.3.8-1

GPU: AMD Ryzen 7 PRO 4750U with Radeon Graphics
GL_VERSION: 4.6 (Compatibility Profile) Mesa 23.1.1
GL_RENDERER: AMD Radeon Graphics (renoir, LLVM 15.0.7, DRM 3.52, 6.3.0.11.realtime1-1-rt)

On a SteamDeck with the same versions, for each example a window opens
for a couple of seconds with transparent content and then sbcl
crashes.

Any help what I could check is appreciated.

BTW: cl-opengl with glut and sdl2 work without any issues on that machine.

does def callback block printing to repl?

I try to call princ and format inside a def callback to print the key value when pressed, but I do not get an output. I don't want to print the keys to show up in the title bar like in the event.lisp example. Is there anyway to do this?

Just a thought about init/terminate

I'm not sure about this, but I think I want to take responsibility for doing this myself, rather than wrapping everything inside with-init.

For bigger, more ambitious projects (I'm thinking of multiple transient windows), it seems like this would help make the structure a little less complicated.

Then again, the alternative is just to do what that macro's doing manually, so I don't know whether it's actually worth making the change. It would take more time to discuss the merits than it would to just do it.

I have this done, if you think it's worth adding. If not, I'm more than a little tempted to just roll it back and forget that I ever had the thought.

I'm glad my last patch helped. Your changes were definitely an improvement. Thanks for doing this. It's so much better than the cobbled-together version I was trying.

Ubuntu: Floating-point-invalid-operation

* (cl-glfw3-examples:basic-window-example)

debugger invoked on a FLOATING-POINT-INVALID-OPERATION in thread
#<THREAD "main thread" RUNNING {100399C4D3}>:
arithmetic error FLOATING-POINT-INVALID-OPERATION signalled

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [STOP ] Stop the task.
1: [ABORT] Exit debugger, returning to top level.

(CL-GLFW3:CREATE-WINDOW
 :WIDTH 600
 :VISIBLE T
 :SAMPLES 0
 :HEIGHT 400
 :SHARED NIL
 :RED-BITS 8
 :STEREO NIL
 :CLIENT-API
 :OPENGL-API
 :MONITOR NIL
 :RESIZABLE T
 :DECORATED T
 :BLUE-BITS 8
 :GREEN-BITS 8
 :ALPHA-BITS 8
 :DEPTH-BITS 24
 :AUX-BUFFERS 0
 :NO-ROBUSTNESS
 :STENCIL-BITS 8
 :REFRESH-RATE 0
 :OPENGL-PROFILE
 :ACCUM-RED-BITS 0
 :SRGB-CAPABLE NIL
 :ACCUM-BLUE-BITS 0
 :ACCUM-GREEN-BITS 0
 :ACCUM-ALPHA-BITS 0
 :CONTEXT-ROBUSTNESS
 :OPENGL-ANY-PROFILE
 :TITLE "Window test"
 :CONTEXT-VERSION-MAJOR 1
 :CONTEXT-VERSION-MINOR 0
 :OPENGL-DEBUG-CONTEXT NIL
 :OPENGL-FORWARD-COMPAT NIL)

Add glfwSetWindowAttrib

Hi!
It seems that glfwSetWindowAttrib is missing. Perhaps it's there, but I'm missing something?

[doubt] Do I need glew?

Hello, I'm studying opengl and I'm trying some things with lisp.
For my surprise I need only the cl-opengl and glfw for doing things in lisp.
But I have learned that each implementation of opengl can be different for each graphic device. So we need some library like glew to be sure of versions and implementations of real calls to a graphic device.
Am I right about that?
is it ok make things in openGl by lisp bindings without glew(or other way to do its work)?

thanks in advance.

Does not install with Windows 7 + SBCL + quicklisp + MinGW?

I've been trying to get this to load using:

(ql:quickload :cl-glfw3)

and continue to receive the following

To load "cl-glfw3":
Load 1 ASDF system:
cl-glfw3
; Loading "cl-glfw3"
; c:/msys/1.0/bin/gcc.exe -m32 -I/quicklisp/dists/quicklisp/software/cffi_0.14.0
/ -o C:\Users\sb3rg\AppData\Local\common-lisp\cache\sbcl-1.1.4.0.mswin.1288-90ab
477-win-x86\c\quicklisp\dists\quicklisp\software\cffi_0.14.0\libffi\libffi-win32
.exe C:\Users\sb3rg\AppData\Local\common-lisp\cache\sbcl-1.1.4.0.mswin.1288-90ab
477-win-x86\c\quicklisp\dists\quicklisp\software\cffi_0.14.0\libffi\libffi-win32
.c

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "main thread" RUNNING {23D
A8B69}>: Couldn't fork child process: No error

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry # on #<GROVEL-FILE "
cffi-libffi" "libffi" "libffi">.
1: [ACCEPT] Continue, treating # on #<
GROVEL-FILE "cffi-libffi" "libffi" "libffi"> as having been successful.
2: [ABORT ] Give up on "cl-glfw3"
3: Exit debugger, returning to top level.

(SB-EXT:RUN-PROGRAM "c:/msys/1.0/bin/gcc.exe" ("-m32" "-I/quicklisp/dists/quickl
isp/software/cffi_0.14.0/" "-o" "C:\Users\sb3rg\AppData\Local\common-lisp
cache\sbcl-1.1.4.0.mswin.1288-90ab477-win-x86\c\quicklisp\dists\quicklisp
software\cffi_0.14.0\libffi\libffi-win32.exe" "C:\Users\sb3rg\AppData\Loc
al\common-lisp\cache\sbcl-1.1.4.0.mswin.1288-90ab477-win-x86\c\quicklisp\d
ists\quicklisp\software\cffi_0.14.0\libffi\libffi-win32.c") :WAIT T :SEARCH
T :INPUT NIL :IF-INPUT-DOES-NOT-EXIST NIL :OUTPUT NIL :IF-OUTPUT-EXISTS :ERROR
:ERROR :OUTPUT :IF-ERROR-EXISTS :ERROR :STATUS-HOOK NIL :EXTERNAL-FORMAT :DEFAUL
T)

Is this a known issue with SBCL?