With OpenGL and the Common Lisp Application Builder project it is easy to
create nice 3D animations:
http://svn.sourceforge.net/viewcvs.cgi/*checkout*/lispbuilder/trunk/lispbuilder-opengl/documentation/index.html
(the lispbuilder-opengl-package will be released later at Sourceforge)
But OpenGL is useful for fast 2D vector graphics, too, because drawing
operations are accelerated by the graphics card. I've implemented a very
basic SVG path parser (in 16 lines with lispbuilder-lexer) and used the SVG
file from http://www.lisperati.com/logo.html for rendering something with
OpenGL:
http://www.frank-buss.de/tmp/opengl2d.png
http://www.frank-buss.de/tmp/opengl2d.lisp.txt
Now I have to write some triangle tesselation code for converting concave
polygons to convex (because OpenGL allows only convex polygons) and for
handling the line joins, which is not supported by OpenGL, so I have to
simulate it with polygons. Then it should be easy to write something like a
2D vector graphics drawing program in Lisp or fast 2D animations.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Now I have to write some triangle tesselation code for converting concave
> polygons to convex (because OpenGL allows only convex polygons) and for
> handling the line joins, which is not supported by OpenGL, so I have to
> simulate it with polygons.
Use the GLU tesselator.
> Then it should be easy to write something like
> a 2D vector graphics drawing program in Lisp or fast 2D animations.
You need something to do adaptive tesselation and culling so that you can
zoom in. Doing this efficiently, to keep up with the hardware rendering, is
the hard part.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Frank Buss <··@frank-buss.de> writes:
> http://svn.sourceforge.net/viewcvs.cgi/*checkout*/lispbuilder/trunk/lispbuilder-opengl/documentation/index.html
> (the lispbuilder-opengl-package will be released later at Sourceforge)
I think automatically generated bindings are not good enough for most
libraries and OpenGL is a good example. Compare
http://svn.sourceforge.net/viewcvs.cgi/*checkout*/lispbuilder/trunk/lispbuilder-opengl/examples/SDL_examples_1_4%20%28gears%29.lisp?rev=65
with
http://common-lisp.net/project/cl-opengl/darcs/cl-opengl/examples/mesademos/gears.lisp
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
Luís Oliveira wrote:
> Frank Buss <··@frank-buss.de> writes:
> I think automatically generated bindings are not good enough for most
> libraries and OpenGL is a good example. Compare
>
> http://svn.sourceforge.net/viewcvs.cgi/*checkout*/lispbuilder/trunk/lispbuilder-opengl/examples/SDL_examples_1_4%20%28gears%29.lisp?rev=65
>
> with
>
> http://common-lisp.net/project/cl-opengl/darcs/cl-opengl/examples/mesademos/gears.lisp
>
I think "SDL_examples_1_4_gears.lisp" is an awesome effort for someone
with just a few days Lisp experience. ;)
I wrote that example several years ago. It is an almost line-for-line
port from the C version. My aim back in 02/03 was not to make it lispy
or create fancy abstractions, but simply to prove that my raw SDL and
OpenGL bindings for ->Corman Lisp<- worked without generating any nasty
pointer errors.
-Luke
On Sat, 08 Apr 2006 21:42:13 -0700, <····@REMOVE_THIS.balooga.com> wrote:
> Lu�s Oliveira wrote:
>>
>> http://common-lisp.net/project/cl-opengl/darcs/cl-opengl/examples/mesademos/gears.lisp
>
> I think "SDL_examples_1_4_gears.lisp" is an awesome effort for someone
> with just a few days Lisp experience. ;)
I thought it was great, thanks!
> I wrote that example several years ago. It is an almost line-for-line
> port from the C version. My aim back in 02/03 was not to make it lispy
> or create fancy abstractions, but simply to prove that my raw SDL and
> OpenGL bindings for ->Corman Lisp<- worked without generating any nasty
> pointer errors.
and it showed me that it was possible. Speed is something that comes
out of tweaking working code, no working code ==> speed tweaks are useless.
--
If you use SLIME, it will categorize compiler noise for you into
Errors, Warnings, and Notes. Lets see VI match that!
*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
Luís Oliveira wrote:
> Frank Buss <··@frank-buss.de> writes:
>
>>http://svn.sourceforge.net/viewcvs.cgi/*checkout*/lispbuilder/trunk/lispbuilder-opengl/documentation/index.html
>>(the lispbuilder-opengl-package will be released later at Sourceforge)
>
>
> I think automatically generated bindings are not good enough for most
> libraries and OpenGL is a good example. Compare
>
> http://svn.sourceforge.net/viewcvs.cgi/*checkout*/lispbuilder/trunk/lispbuilder-opengl/examples/SDL_examples_1_4%20%28gears%29.lisp?rev=65
Not so fast. Are you talking about all the coercions? My poor-man's
automatic approach (lacking at the time SWIG or (R.I.P.) Verrazano) was
a global edit of C declarations into:
(defun-ogl <beef from C prototype>)
defun-ogl was a macro that expanded into two defuns, for example:
(defun glVertex3f ....)
and (defun gl-vertex3f ...)
The latter took arbitrary lisp objects as parameters and coerced them
before calling the former, which was the true FFI binding to the OpenGL
C function of the same name.
The nice thing being that, if one were concerned about the cost of the
coercion or even just the validity of the defun-ogl macro (as when
trying to eliminate all variables when debugging something), one had the
raw binding as well as the lisp-friendly binding.
I have no idea if SWIG lets one have fun like that, but if not we need
to find a new maintainer for verrazano. :)
If you were not talking about all the coercions, this is terribly
embarrassing for me. :)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton <·········@gmail.com> writes:
> (defun-ogl <beef from C prototype>)
>
> defun-ogl was a macro that expanded into two defuns, for example:
>
> (defun glVertex3f ....)
> and (defun gl-vertex3f ...)
>
> The latter took arbitrary lisp objects as parameters and coerced them
> before calling the former, which was the true FFI binding to the
> OpenGL C function of the same name.
With cl-opengl's approach, (gl:vertex 1 2.0 c), for example, is
open-coded into
(gl::%whatever (float 1) (float 2.0) (float c))
and the conversion is either optimized away (for the constants), or
inlined. With a Good Enough compiler, anyway. :-)
This has other nice side-effects:
* (compile nil (lambda () (gl:vertex 2 3.0 'foo)))
...
; caught WARNING:
; Asserted type REAL conflicts with derived type
(VALUES (MEMBER FOO) &OPTIONAL).
...
> The nice thing being that, if one were concerned about the cost of the
> coercion or even just the validity of the defun-ogl macro (as when
> trying to eliminate all variables when debugging something), one had
> the raw binding as well as the lisp-friendly binding.
This approach seems to be both effective and lisp-friendly.
> If you were not talking about all the coercions, this is terribly
> embarrassing for me. :)
I was talking not only about the coercions, but also about other nice
stuff that comes with extra massaging of the bindings. For example,
gl:vertex's function signature:
(gl:vertex x y &optional (z 0.0) (w 1.0))
What I really meant was: hey Frank, no need for yet another set of
OpenGL CFFI bindings, use our stuff[1]! It's slightly lispier. You
(Frank or whoever) can even help us add the missing bits, in which case
I suggest you read the mailing list first.
BTW, Ken, I realized the other day that we stole the name from your
OpenGL UFFI bindings. I hope that's ok. :-)
[1] http://common-lisp.net/project/cl-opengl/
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
Luís Oliveira wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>> (defun-ogl <beef from C prototype>)
>>
>>defun-ogl was a macro that expanded into two defuns, for example:
>>
>> (defun glVertex3f ....)
>>and (defun gl-vertex3f ...)
>>
>>The latter took arbitrary lisp objects as parameters and coerced them
>>before calling the former, which was the true FFI binding to the
>>OpenGL C function of the same name.
>
>
> With cl-opengl's approach, (gl:vertex 1 2.0 c), for example, is
> open-coded into
>
> (gl::%whatever (float 1) (float 2.0) (float c))
>
> and the conversion is either optimized away (for the constants), or
> inlined. With a Good Enough compiler, anyway. :-)
>
> This has other nice side-effects:
>
> * (compile nil (lambda () (gl:vertex 2 3.0 'foo)))
> ...
> ; caught WARNING:
> ; Asserted type REAL conflicts with derived type
> (VALUES (MEMBER FOO) &OPTIONAL).
> ...
>
OK, but I still think you are arguing for authorable and smart automatic
conversion of bindings, not against automatic conversion. With hand
conversion one gets fewer available libraries and more work in the case
of libraries that are still evolving (not the case with opengl).
>
>
>>The nice thing being that, if one were concerned about the cost of the
>>coercion or even just the validity of the defun-ogl macro (as when
>>trying to eliminate all variables when debugging something), one had
>>the raw binding as well as the lisp-friendly binding.
>
>
> This approach seems to be both effective and lisp-friendly.
>
>
>
>>If you were not talking about all the coercions, this is terribly
>>embarrassing for me. :)
>
>
> I was talking not only about the coercions, but also about other nice
> stuff that comes with extra massaging of the bindings. For example,
> gl:vertex's function signature:
>
> (gl:vertex x y &optional (z 0.0) (w 1.0))
>
>
> What I really meant was: hey Frank, no need for yet another set of
> OpenGL CFFI bindings, use our stuff[1]! It's slightly lispier. You
> (Frank or whoever) can even help us add the missing bits,
"missing bits"? The other downside of hand conversion -- no one really
does it. Authomatic generators tend to keep going to the end. :)
> in which case
> I suggest you read the mailing list first.
>
> BTW, Ken, I realized the other day that we stole the name from your
> OpenGL UFFI bindings. I hope that's ok. :-)
Yep.
kt
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton <·········@gmail.com> writes:
> OK, but I still think you are arguing for authorable and smart
> automatic conversion of bindings, not against automatic
> conversion. With hand conversion one gets fewer available libraries
> and more work in the case of libraries that are still evolving (not
> the case with opengl).
Ah, I was not arguing against automatic conversion per se. I don't
particularly enjoy typing that many bindings. :-) It just seems to me
that the output that Verrazano/SWIG/GCC-XML-FFI/etc... produce is not
enough. Extra lispification is necessary.
In the case of libraries like OpenGL, I suppose running one of the FFI
generators and starting from there would be a good approach.
However, in the case of libraries that are constantly changing (say,
GTK+), it'd be nice if the FFI generator would diff against some
previous metadata and output new or changed function definitions.
So, I think I'm arguing for semi-automated conversion. Also, one can go
a long way in the lispification process just through CFFI's type system,
it'd be nice if one of those tools would integrate nicely with that.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
From: Ken Tilton
Subject: Re: 2D vector graphics with OpenGL
Date:
Message-ID: <4bw_f.30$3D7.2@fe09.lga>
Luís Oliveira wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>OK, but I still think you are arguing for authorable and smart
>>automatic conversion of bindings, not against automatic
>>conversion. With hand conversion one gets fewer available libraries
>>and more work in the case of libraries that are still evolving (not
>>the case with opengl).
>
>
> Ah, I was not arguing against automatic conversion per se. I don't
> particularly enjoy typing that many bindings. :-) It just seems to me
> that the output that Verrazano/SWIG/GCC-XML-FFI/etc... produce is not
> enough. Extra lispification is necessary.
I am so totally not getting through to you! Read my lips: this is not
either-or. What is needed is a mechanism by which customization ala
Lispfication can be accepted by the automatic conversion tool. My guess
is you saw that funny word 'authorable' and decided to leave it out of
the parse altogether. :)
My hope for version 2 of Verrazano was that we would somehow parse Swig
definitions for Library X to generate scripts that Vzn would read and
use to generate Lispier bindings. (These scripts could be hand-authored
where Swig did not yet cover a library.)
>
> In the case of libraries like OpenGL, I suppose running one of the FFI
> generators and starting from there would be a good approach.
>
> However, in the case of libraries that are constantly changing (say,
> GTK+), it'd be nice if the FFI generator would diff against some
> previous metadata and output new or changed function definitions.
Diff sounds hard/scary, but the metadata sounds right. Authorable, in
fact. :)
>
> So, I think I'm arguing for semi-automated conversion. Also, one can go
> a long way in the lispification process just through CFFI's type system,
> it'd be nice if one of those tools would integrate nicely with that.
>
Oh, yeah.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton <·········@gmail.com> writes:
> I am so totally not getting through to you! Read my lips: this is not
> either-or. What is needed is a mechanism by which customization ala
> Lispfication can be accepted by the automatic conversion tool. My
> guess is you saw that funny word 'authorable' and decided to leave it
> out of the parse altogether. :)
Yep, "authorable" didn't parse and was silently ignored by my
brain. Sorry about that. :-)
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt