September 2008 - cl-opengl-devel - mailman3.common-lisp.net

[cl-opengl-devel] Patch to support anisotropic texture filtering
by Mikael Lax 06 Sep '08

06 Sep '08

Hi all, attached is a tiny patch to add support for the anisotropic texture filtering extension (just another case in tex-parameter). Sincerely, Mikael Lax

2 1

[cl-opengl-devel] bug in render-to-texture example?
by Johann Korndoerfer 02 Sep '08

02 Sep '08

Hi When invoking the misc/render-to-texture.lisp example the second time (the first time works perfectly), the whole screen flickers black although the example runs windowed. After pressing esc, the flickering stops but the glut window stays open. The lisp is still alive, but no calls to gl will have any effect so i have to restart sbcl to continue working. This may be a bug in opengl or the graphics card driver (nvidia's in my case) that does not surface when programming in C (creating multiple contexts one after another is not a common use case since you restart everything all the time). Explicitly deleting the framebuffer, renderbuffer and texture objects did not help. I eventually succeeded in creating a workaround as follows: Unbind the texture after it has been drawn onto the quads, then draw another, untextured quad (e.g. of size zero). Which does not make any sense at all. Does anybody have the same problems? Johann

2 3

Re: [cl-opengl-devel] OpenGL 3.0
by Bart Botta 02 Sep '08

02 Sep '08

On Mon, Aug 18, 2008 at 1:29 PM, Luís Oliveira <luismbo(a)gmail.com> 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. > Can anyone remind me why were they collapsed into one enum? 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). Only thing i could find in the list archives is that it is harder to deal with returning enums, though seems like at worst we could just have a combined set used for doing the reverse translations in that case. Also, looking at the glGet*, is there any reason we don't just map all of those to gl:get and add a compiler macro (or whatever) to pick the correct low level version? looks like the enum.spec files might even have enough info to map most of the enums to types, though probably have to pick out the ones that should be interpreted as enums by hand. -b-

2 5