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
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
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
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
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
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
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
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
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
(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
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
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
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
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,
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-
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
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
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.
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
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
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
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
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
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,
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)
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
26 matches
Mail list logo
