Re: OT: cpu spiking
It sounds like you are running without vsync on one of the drivers, which means you are displaying frames as fast as you can. "As fast as you can" usually means either "100% CPU" or "100% GPU" (sometimes "100% RAM or bus bandwidth"). Check the settings for the driver to see if vsync has been forced to off, or defaulting to off. I don't think there is an easy way to control vsync from glut (and drivers can ignore what programs say anyway), but for a test you can try something like: #+unix (let ((p (glut:get-proc-address "glxSwapIntervalEXT"))) (unless (cffi:null-pointer-p p) (cffi:foreign-funcall-pointer p () :int 1 :int))) ;; 0 to disable vsync, 2 to run at half monitor frame rate, etc in glut:display-window :before Note that just checking for a null pointer like that is wrong, and you should be checking for the presence of the extension first, which would require some more work with CFFI to get and parse the glx extension string. For the case where you aren't drawing anything, I think 100% CPU is expected. Per freeglut docs, the idle callback is "called continuously from freeglut while no events are received", which sounds like it would use 100% CPU. You might try using glut:tick instead (with :tick-interval argument to window instance creation), as in the shader-vao example, which runs on a timer instead of constantly. On Sun, May 29, 2022 at 1:46 PM Orm Finnendahl wrote: > > Hi, > > I might have been a bit unprecise and I just found out it might be > off topic for this list (see below): This is all related to my laptop > running an AMD ryzen 7 integrated cpu/gpu on a linux arch system with > latest sbcl/slime/emacs. > > Running (cl-glut-examples:gears) using the open source radeon driver, > everything works as expected and the REPL reports a framerate of 60 > fps. > > Using the closed source pro driver of amd, the framerate goes up to > ca. 1000 fps and the cpu maxes out. Putting a timer in the display > function (calling #'glut:post-redisplay), the framerate goes down, but > the cpu is still above 100%. > > I just found out that this is also true for the glxgears program: > running it with the open source driver give 60 fps, using it with the > pro driver gives 12000 fps and the cpu maxes out. > > Even as this therefore seems to be more realted to the graphics driver > than cl I'd still appreciate if anyone has an idea, how to deal with > this... > > > -- > Orm > >
Re: Blending
On Mon, Nov 11, 2013 at 2:05 PM, Greg Bennett gwbenn...@sentex.ca wrote: glClearColor(1.0, 10., 1.0, 0.0); glBlendFunc(GL_ONE, GL_ONE); glEnable(GL_BLEND); (gl:clear-color 1.0 1.0 1.0 0.0) ;; assuming 10. was a typo (gl:blend-func :one :one) (gl:enable :blend)
Re: Confused as to how generate-gl-function works
On Wed, Oct 30, 2013 at 6:58 AM, Chris Bagley chris.bag...@gmail.comwrote: We use runtime compiling to create our wrappers in case functionality is not present. Runtime compilation is more of an optimization, we could store the function pointers in a closure or global array or something instead (and in fact probably should store them differently to be handle multiple drivers on windows correctly, but making that correct/efficient would probably be harder even though not many people would need it.) That is great, but how do more static languages that don’t have this kind of control handle multiple versions of opengl? In C/C++ you can call a function pointer exactly the same way as a normal function, so they usually just define a bunch of function pointers for the extension functions and initialize them all at once. Most people probably use a library like GLEW or GLEE for that.
Re: Confused as to how generate-gl-function works
On Wed, Oct 30, 2013 at 3:47 PM, Caelan Burris caelanbur...@gmail.com wrote: IIRC, GLEW basically loads as many functions as possible from a static list of names, and provides an error thunk for any names it can't load. So the short version for GLEW is basically, They don't. As far as I know, GLEW generates its static list of names from the specifications, so GLEW handles it pretty much exactly as much as cl-opengl does (I think it uses the text of the specifications rather than the data files cl-opengl uses, but should produce approximately the same results).
Re: Confused as to how generate-gl-function works
On Wed, Oct 16, 2013 at 8:58 AM, Chris Bagley chris.bag...@gmail.com wrote: Cheers, good to know. OK going back and reading the code again, this all seems to boil down to the fact that some implementations of opengl are missing functions It is mainly intended for OpenGL extensions, but Windows in particular only supports gl 1.1 or 1.4 or so in the system libraries, so everything beyond that has to be loaded the same way. Other systems might be able to link more functions directly, but I'm not sure it would be worth the effort to try to figure out which ones, particularly since it might depend on drivers or hardware so needs to be checked at runtime anyway. Does the resulting lisp program take a performance hit from having such a late compile? I think the runtime compilation was intended to improve performance, by compiling a specific function containing the function pointer directly rather than precompiling a function that would have to look it up somewhere for every call. That way the first call is a bit expensive, but every call after that can be as fast as possible. No idea how much difference it actually makes, or if it depends on lisp implementation or platform though. It's a heck of an interesting problem, I hadn't really thought about how cl-opengl handled versions before. It's a pretty cool solution! Are there any features around this area that that need implementing or improvements to code that are needed? My main part time project totally relies on cl-opengl so it would be nice to give a little back! Can't think of anything in that specific area that needs work, but there is lots of room for improvement in the high-level api (the GL: package) part of cl-opengl, particularly with more modern style of OpenGL programming (shaders, vbos, etc).
Re: glClearColor not found on some machine, some CL system
Sounds like https://github.com/3b/cl-opengl/issues/42 which is fixed in the git repo at https://github.com/3b/cl-opengl and should be in next quicklisp update. On Fri, Oct 4, 2013 at 4:39 AM, Rujia Liu rujia@gmail.com wrote: I've tested on 3 other machines. 2 with OpenGL 2.1 and 2 with OpenGL 4.3 It seems that OpenGL 2.1 machines can run SBCL executable while OpenGL 4.3 cannot. But on all machines ccl executable cannot run. I don't think glClearColor has changed between OpenGL 2.1 and OpenGL 4.3, from the latest reference: http://www.opengl.org/sdk/docs/man/xhtml/glClearColor.xml So I'm confused. Any help would be appreciated. Thanks!!! - Rujia On Fri, Oct 4, 2013 at 5:26 PM, Rujia Liu rujia@gmail.com wrote: Hi! I'm new to cl-opengl and was reading this tutorial: http://nklein.com/2010/06/nehe-tutorial-02-drawing-triangles-and-quadrilaterals/ I've downloaded tut02.lisp, but have trouble running it. On my machine, ccl 1.6 (windows XP, 32 bit, OpenGL 1.5) gives: ; Warning: Don't know how to setup a hook before saving cores on this Lisp. ; While executing: #Anonymous Function #xCE06D0E, in process listener(1). Error: Couldn't find function glClearColor While executing: CL-OPENGL-BINDINGS::GENERATE-GL-FUNCTION, in process listener (1). Type :GO to continue, :POP to abort, :R for a list of available restarts. If continued: Skip loading tut02.lisp Type :? for other options. But SBCL 1.1.4 (win32-thread fork) runs perfectly. On another machine (windows 7, 64 bit, OpenGL 4.3), both ccl 1.6 and SBCL (both 32-bit) gave the error message before. Could anyone give me some suggestions? Thanks in advance - Rujia
Re: cl-opengl and current Clozure Lisp 1.9 (32 and 64-bit) on Windows 7
Should be fixed in git (https://github.com/3b/cl-opengl see also https://github.com/3b/cl-opengl/issues/42), which should be in next quicklisp, or you can clone that repo into quicklisp local-projects directory until then. More testing (particularly on windows and mac) before then would be good though.
Re: [cl-opengl-devel] CL-OpenGL ES?
On Wed, Jun 29, 2011 at 9:10 AM, Luís Oliveira luis...@gmail.com wrote: On Wed, Jun 29, 2011 at 2:56 PM, Simon Ortiz o.si...@gmail.com wrote: For our first approach, I'll do a cl-opengl-es-1.1 system which will depend on cl-opengl as is. I'll write the CFFI definitions for the egl* functions by hand. I guess I'll define the fixed-point data type by hand too. Yes, that's my suggestion. If I understand correctly, EGL is something like glx/wgl/etc, and isn't actually part of OpenGL ES itself, so I'd probably lean towards a separate cl-egl system containing just the EGL parts. If ES 1.x only adds data types, I'd probably include them in the main cl-opengl for now. If there are conflicting function signatures or enums things would be more complicated... not sure what the best solution for that would be. -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] CL-OpenGL ES?
I don't really know much about OpenGL ES, beyond what has been inherited by WebGL... On Mon, Jun 27, 2011 at 9:16 AM, Luís Oliveira luis...@gmail.com wrote: On Mon, Jun 27, 2011 at 3:04 PM, Simon Ortiz o.si...@gmail.com wrote: I got carried away with OpenGL ES, which lamentably isn't. Specifically, ES 2.0 is not compatible with ES 1.1 :( I think cl-opengl supports http://www.opengl.org/registry/specs/ARB/ES2_compatibility.txt, so it should at least be close to ES 2.0. Don't know if the functions are exact matches or just something similar though. My understanding is that, API-wise, OpenGL ES is a subset of GL plus set of egl* functions. Is that correct? The former can be carved out of the existing code. To generate bindings for egl* functions, the way to go would be to throw the OpenGL ES spec at the current spec-parsing code and see what happens. The spec that cl-opengl parses is a more-or-less machine readable file available at http://www.opengl.org/registry/, not the actual specification. I'm not aware of anything similar for ES, so if the functions are not included in the main .spec files some other strategy would be required. I'd probably just parse the .h files to get a rough translation then edit it by hand from there, if the versions don't overlap as much as desktop GL. -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] Unkown option: CONVENTION
On Tue, Aug 24, 2010 at 7:46 PM, Kevin Smith k2msm...@gmail.com wrote:
Anyone know why I am getting this warning now ?
; loading system definition from
; /Users/kevinsmith/sbcl-lisp/cl-opengl/cl-glu.asd into #PACKAGE ASDF0
; registering #SYSTEM CL-GLU {1002C81C61} as CL-GLU
WARNING: Unkown option: CONVENTION
Try upgrading cffi.
-b-
___
cl-opengl-devel mailing list
cl-opengl-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
[cl-opengl-devel] no longer calling glut:init at load time
I disabled the call to glut:init when cl-glut is loaded, since it was breaking things that just want to load the code (to verify it compiles, check dependencies, build a binary, or whatever) but don't have a display available, and I'm guessing it wasn't helping with the threading problems on OSX either. If anyone runs into problems because of that, please file a bug or send a message to the list, so we can try to work out a better compromise between use-cases that need it initialized and those that need it not initialized. -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] [Openmcl-devel] Trace/BPT trap with cl-opengl loading
On Mon, Aug 2, 2010 at 11:41 AM, Kevin Smith k2msm...@gmail.com wrote: ; Warning: Don't know how to setup a hook before saving cores on this Lisp. That warning just means you can't reliably save a core if you have called any OpenGL functions, it shouldn't affect anything for normal usage. -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] OpenGL 3.3/4.0 bindings
On Sat, Mar 13, 2010 at 6:28 PM, Luís Oliveira luis...@gmail.com wrote: Any reason why we shouldn't make this the official branch and adjust the webpage links? (And should we point to the issue tracker as well?) OK with me, though if people actually started using the issue tracker very much, I'd probably want to move it somewhere better. I think the only major regression from the darcs tree is that the auto error checking breaks rather badly when used with multiple contexts, but at least that isn't too hard to disable, and seems useful otherwise. -- b ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
[cl-opengl-devel] OpenGL 3.3/4.0 bindings
I've updated the low level bindings (%gl package) in my cl-opengl fork at http://github.com/3b/cl-opengl to version 60 of the .spec files, including gl 3.3 and gl 4.0. Only minimally tested, but shouldn't have any effect on existing code aside from a few extension functions whose names changed (named-make-buffer-resident-nv and named-make-buffer-non-resident-nv are make-named-* now), an OpenGLES-only enum name change (:writeonly-rendering-amd to :writeonly-rendering-qcom), and the disappearance of framebuffer-texture-face, but that doesn't seem to be in the specification either. see http://github.com/3b/cl-opengl/issues for a list of known issues, feel free to add more if you run into any problems with it. -- b ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
[cl-opengl-devel] gl 3.2
I've updated my fork to gl 3.2 and latest extensions as of 2009-09-11 (GL_EXT_VERSION 55), and merged it with the current darcs tree : http://github.com/3b/cl-opengl In addition to updating to current GL version, this tree has automatic GL error checking, which can be disabled at by pushing :cl-opengl-no-check-error onto *features* before compiling cl-opengl (calling code must be recompiled too, since the functions are declaimed inline.) Due to duplicated names in %gl:enum, gl:get-error, gl:check-framebuffer-status, and gl:check-framebuffer-status-ext (and a few other functions that i don't think existed in the main tree anyway) return :unsigned-int instead of %gl:enum now, so some existing code might break with this tree. There is currently gl::enum= for comparing %gl:enum values to the numerical values, and to each other by value. Not sure if that is the final API or not yet, so feedback on whether that is enough for actual usage or not would be good. other features/changes: gl:get* - for known queries, determines number and type of value(s) to return automatically. Should know about everything through gl 3.0 or so, but may not be completely current. Needs a better name, so that might change... uses cffi:bitfields for various arguments, so the short names (without the -bit suffix) don't conflict with other enums, probably not visible to most user code that wasn't running into the conflicts, but anything dealing with the values directly might need modified. various bugfixes, export more %gl: functions from gl:, etc. Unlike my previous gl3 fork, this one doesn't try to split out the core/non-deprecated parts of the GL spec, so it should be easier to keep up to date with newer GL versions/extensions. It also doesn't close glut windows on errors, since that broke the glut:*run-main-loop-after-display* feature used by cl-glut-examples:run-examples, not sure what the correct way to handle that is. This tree hasn't been tested much beyond sbcl/linux/x86_64, so more testing would be welcome. -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] GLenum return values
On Sat, Sep 12, 2009 at 4:46 PM, Luís Oliveiraluis...@gmail.com wrote: What about splitting gl:enum back into multiple ones like it used to be? Perhaps keeping the big enum, since it makes sense for some of the functions, I suppose. Could we generate this automatically from the spec? Doesn't help, since there are cases where a particular value has multiple names, even when returned by the same function. For example when an extension adds a value, with -foo on the name, then it gets added to the core without the -foo, but the same value. So code using the extension should check for the -foo name, while code using the newer GL version should check for the name without -foo, even though both are actually looking for the same numerical value. (and it would probably be hard to generate automatically from what I remember of trying to do so last time) -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] edge-flag-array and tex-coord-array fix
(just realized that this appears to have never reached the list, responding so people with commit access can see it too...) On Thu, Mar 26, 2009 at 9:33 AM, Brad Beer bradwb...@gmail.com wrote: I have a (possible) fix for my edge-flag and tex-coord arrays. Please let me know if I am submitting this correctly. would be better to have one of the formats that shows which file it is, try diff -Nau or darcs diff 191c191 (tex-coord-pointer ,size ,gl-type ,stride ,address-expr --- (,func-name ,size ,gl-type ,stride ,address-expr 193,194c193 `(edge-flag-pointer ,stride ,address-expr)) (vertex-attrib --- `(,func-name ,stride ,address-expr)) (vertex-attrib looks right (aside from apparently losing a newline), probably should do the same thing for vertex-attrib-pointer a few lines down given the choice, i'd probably pull that whole API out into a contrib until it stabilized though (and add a contrib/extension setup of some sort to cl-opengl in the process...) -- -3b ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] problem with vertex arrays
On Wed, Sep 10, 2008 at 6:55 AM, Sebastian Berchtold [EMAIL PROTECTED] wrote: This leads me to the following questions: Whats the difference between the %gl: und the gl package? it spent some time on it but didnt get it %gl: is for the C level bindings, which take exactly the arguments the C functions take, so you need to pass C pointers where expected instead of lisp data structures, and uses specific data types, etc. %gl is mostly autogenerated, so has everything C has. gl: is the lisp side of the API, which uses lisp data structures, and handles (some) data type translations for you, etc. but is hand written, so less complete. %gl is mainly for implementing the gl package, but is also available for implementing higher level abstractions when going through gl would be inefficient. Does anybody know how to fix that?^^ implement gl:vertex-pointer, or allocate a C array using cffi, store the vertices in it, and pass that to %gl:vertex-pointer (make sure to deal with memory management, etc. properly by hand in that case, since GC can't deal with it for you) Does this example run on somebody elses machine? Probably not, which is probably why it isn't loaded by default :) Those APIs are sort of hard to wrap nicely, since they may need to keep pointers around, and that sort of thing, so they aren't quite done yet. I think there is an example of the current code for that in examples/misc/opengl-array.lisp. -- b ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] OpenGL 3.0
After looking at it a bit more, I think trying to split out the enums is going to be too much work to block gl3 support for (and possibly too much work in general). The .spec files have lots of parameters mapped to enum directly, many of the enums that do exist are incomplete or need split into multiple enums, etc. so it would pretty much require just going through the spec/extensions and building the list by hand anyway. So for the problem of clashes with the aliases for enums with -BIT names, I'll try splitting those out by hand, and the rest can stay in the big enum for now. Any objection to removing the aliases that were auto-generated for the names that end with _BITS but aren't bitfields? (usually queries for # of bits in something) -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] OpenGL 3.0
On Mon, Aug 18, 2008 at 3:05 PM, Bart Botta [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 1:29 PM, Luís Oliveira [EMAIL PROTECTED] wrote: Actually, I wouldn't mind seeing the per-function enums come back. Having compile-time warnings when we passed a bogus keyword was nice. Sounds like a reasonable thing to have, if we can generate it easily (which we can't for GL3 at the moment, since there are not complete .spec files available yet). OK, after looking at the full gl3 .spec files, it looks like we can't generate all of the function specific enums automatically. It looks like it has some of the older enums split out, but not sure if they include all the newer extensions or not. Probably could build up a full set of enums, if we don't mind giving up on being able to completely regenerate the enums automatically. I've been thinking that might be a good idea in general though (the not fully automatic bindings part), since GL naming isn't consistent enough to rely on the automatic stuff for new function names anyway, so currently adding new extensions requires a few passes of proofreading the generated bindings and editing the generator. Does it sound reasonable to split the binding generation into 3 steps, only 2 automatic: First would parse the .spec files, tracking any enum groups defined in the file, approximately splitting up function names, etc. and write the results to some lispy format (reusing output of step 2 if available). Second step would be editing the generated data by hand, adding missing enum groups, fixing word breaks that the automatic code got wrong, etc. Third would be parsing the hand edited code to generate the actual bindings. -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] OpenGL 3.0
On Sat, Aug 30, 2008 at 5:27 PM, Luís Oliveira [EMAIL PROTECTED] wrote: Sounds good to me. It'd be great if this process could somehow highlight changes in the spec so that step 2 can be focused on what changed instead of having to review everything. Yeah, that was the idea, though I'm leaning towards just letting the version control deal with highlighting the changes. -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
[cl-opengl-devel] OpenGL 3.0
OpenGL 3 spec has been released: http://www.opengl.org/registry/doc/glspec30.20080811.pdf Instead of the originally planned rewrite, it ended up being just more stuff piled onto the old API, but they did add a mechanism for deprecating old features, and a way to create contexts which cannot use deprecated features. Any opinions on adding a cleaned up, gl3+ only version of cl-opengl which doesn't support the deprecated features or most of the older extensions, either as a fork, a separate mode for the main codebase (alternate .asd or with compile time checks), or some other way? --- -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] division-by-zero error
On 3/5/08, James Baker [EMAIL PROTECTED] wrote: ok well, using (sb-int:with-float-traps-masked (:invalid :divide-by-zero)) as suggested by Luís allows me to load cl-glut-examples, but the issue still occurs if i try to run an example (i.e. rb-hello) well, you could try adding the with-float-traps-masked when you call rb-hello as well, but seems like it would be better to try to figure out what is breaking first... backtrace from there is = 'from there' = from calling rb-hello? Do you get the same backtrace when loading cl-glut-examples without the with-float-traps-masked? 7: (foreign function: interrupt_handle_now) hmm, not much useful there. It didn't go any farther than that? -- -b- ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] textures
On 9/8/07, Tudor Achim [EMAIL PROTECTED] wrote: Hi, I'm following nehe's tutorials at nehe.gamedev.net, and I'm having a lot of trouble with loading and binding textures. Which one(s) are you looking at? I opened a stream to the bmp file with (setf test (open /home/tudor/email.bmp :element-type '(cl-user::unsigned-byte 8))) Then, I made an 1d array of 5000 elements (just so it was 'big enough') and stored the rgb values in it with (read-sequence test-array test) You'll probably need something more complicated than that (to deal with the BMP file format, etc), but it should at least give you something that would show up if you uploaded it correctly... (though are you sure that is actually 'big enough' for your file? that would only be around 40x40 pixels if I'm counting right.) However, when I do (gl:bind-texture gl:tex-image-2d test-array), it says that cl-opengl:tex-image-2d is unbound. There are a few things wrong here: First, you probably want :tex-image-2d instead of gl:tex-image-2d, cl-opengl converts most OpenGL enums ( things like GL_FOO_BAR in C source) to keywords in lisp (so :foo-bar for GL_FOO_BAR). Next, bind-texture should be taking a GL texture name (an int) as the second parameter, not the actual texture data. You need to allocate a texture name with gl:gen-textures and store that somewhere (and remember to deallocate it later). Then you need to set up the texture, first make it the current texture with bind-texture, then you will probably want some tex-parameter calls to set filtering, and finally upload the image data with tex-image-2d. The tex-image-2d call is where you would pass the test-array parameter you loaded above. If you are only using 1 texture, then you should be able to go from there, otherwise repeat that for each texture, and call bind-texture during rendering to activate the particular you need for a batch of geometry. -- Bart ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Re: [cl-opengl-devel] Installing cl-opengl
On 7/24/07, Gatewood, Walter P. CIV NAVAIR [EMAIL PROTECTED] wrote: ... Are there are step-by-step instructions somewhere on the web that would be helpful in getting it to work again? Not tested since I'm stuck in windows at the moment, but should at least be close... cd ~/.sbcl/site darcs get http://common-lisp.net/~loliveira/darcs/cl-opengl-thomas/ darcs get http://common-lisp.net/project/cffi/darcs/cffi/ cd ~/.sbcl/systems ln -s ../site/cl-opengl-thomas/*asd . ln -s ../site/cffi/*asd . then in sbcl, (require 'asdf) (asdf:operate 'asdf:load-op 'cl-opengl) should work. -- Bart ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
[cl-opengl-devel] generating function bindings, extension loading
I've been working on generating bindings from the .spec files on opengl.org, and it seems to be to the point where it could be turned into a patch... Before that though, I wanted to get some feedback about changing the naming for the bindings: First suggestion is moving the function bindings to a separate package, and giving them lisp style names, so people like me who want to use them directly have supported access to them. Second is changing the GLenums from cffi:defcenums to defconstants. Advantages I can think of from doing that: *Easier for users to add enums from a new extension without modifying library code (unless cffi allows adding to an enum after it is defined, not sure about that) *Easier to add offsets to them, for example a loop to disable all lights could use (+ index gl:+light0+) instead of having to convert from enum and back, or store a list of the light enums or whatever. *being able to add offsets also solves the problem of some values (light in particular) potentially having more valid values than are enums. (The .spec files name 8 lights, but leaves room for 4096, I'm pretty sure there has been hardware supporting at least 32.) *compatibility with other bindings (glx and cl-sdl both use +foo+ style for enums if I remember correctly) *possibly speed. If cffi can remap values at compile time it probably isn't too bad, but it probably wouldn't be too hard to find code with a lot of enums specified at runtime. (Alternately, is it possible to tell cffi to allow using either the constants or the keywords?) Also, a small patch: someone in #lisp was having problems with OpenMCL objecting to compute-applicable-methods being called with extra arguments in glut/interface.lisp, which was fixed by the following patch to define-glut-event: diff -rN old-pct/glut/interface.lisp new-pct/glut/interface.lisp 130c130 :func ',event-func :arg-count ,(length args)) --- :func ',event-func :arg-count ,(length arg-names)) ___ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
