For my own knowledge does anyone (Kenny?) know the differences between
the cl-opengl that comes with Cello and the cl-opengl project on
common-lisp.net. I'm looking into graphics packages and I would like
to check out both Cello and OpenGL but it looks like I will be
contending with a naming conflict.
Why does Cello have it's own OpenGL bindings? Is that something that
should be rectified? Is Cello compatible with the other cl-opengl?
Sorry for all the questions,
-dustin
Dustin Withers wrote:
> For my own knowledge does anyone (Kenny?) know the differences between
> the cl-opengl that comes with Cello and the cl-opengl project on
> common-lisp.net.
I did mine, they did theirs, they asked if I minded their taking the
name, I did not but then I thought I would be able to switch to theirs.
> I'm looking into graphics packages and I would like
> to check out both Cello and OpenGL but it looks like I will be
> contending with a naming conflict.
The latest Cello now uses kt-opengl, so I guess your client code could
use cl-opengl quite happily without conflict.
>
> Why does Cello have it's own OpenGL bindings?
I decided I really hated what they did with cl-opengl and did not convert.
> Is that something that
> should be rectified?
I think cl-opengl is Completely Wrong on How to Wrap A Library, so you
would need someone madly in love with Cello and cl-opengl to undertake
an irreversible, one-way fork.
> Is Cello compatible with the other cl-opengl?
What's in a name? They all lead to the C functions. Hmmm, maybe the data
would be a problem, since the wrappers probably deviate in how much work
they do before handing off Lisp value to C....ok, maybe not,
hth, kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Jun 10, 12:59 pm, Ken Tilton <···········@optonline.net> wrote:
> The latest Cello now uses kt-opengl, so I guess your client code could
> use cl-opengl quite happily without conflict.
Thanks for that. I didn't see that and I didn't bother to check the
cello.asd file to see if cello was or was not dependent on cl-opengl.
Thanks for clearing it up.
-dustin
Ken Tilton <···········@optonline.net> writes:
> Dustin Withers wrote:
>> For my own knowledge does anyone (Kenny?) know the differences between
>> the cl-opengl that comes with Cello and the cl-opengl project on
>> common-lisp.net.
>
> I did mine, they did theirs, they asked if I minded their taking the
> name, I did not but then I thought I would be able to switch to
> theirs.
>
>> I'm looking into graphics packages and I would like
>> to check out both Cello and OpenGL but it looks like I will be
>> contending with a naming conflict.
>
> The latest Cello now uses kt-opengl, so I guess your client code could
> use cl-opengl quite happily without conflict.
>
>>
>> Why does Cello have it's own OpenGL bindings?
>
> I decided I really hated what they did with cl-opengl and did not convert.
What did you do differently?
Paul Donnelly wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Dustin Withers wrote:
>>
>>>For my own knowledge does anyone (Kenny?) know the differences between
>>>the cl-opengl that comes with Cello and the cl-opengl project on
>>>common-lisp.net.
>>
>>I did mine, they did theirs, they asked if I minded their taking the
>>name, I did not but then I thought I would be able to switch to
>>theirs.
>>
>>
>>>I'm looking into graphics packages and I would like
>>>to check out both Cello and OpenGL but it looks like I will be
>>>contending with a naming conflict.
>>
>>The latest Cello now uses kt-opengl, so I guess your client code could
>>use cl-opengl quite happily without conflict.
>>
>>
>>>Why does Cello have it's own OpenGL bindings?
>>
>>I decided I really hated what they did with cl-opengl and did not convert.
>
>
> What did you do differently?
I did not add a fancy layer of abstraction or change the names of
constants.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton <···········@optonline.net> writes:
> Paul Donnelly wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>>
>>>Dustin Withers wrote:
>>>
>>>>For my own knowledge does anyone (Kenny?) know the differences between
>>>>the cl-opengl that comes with Cello and the cl-opengl project on
>>>>common-lisp.net.
>>>
>>>I did mine, they did theirs, they asked if I minded their taking the
>>>name, I did not but then I thought I would be able to switch to
>>>theirs.
>>>
>>>
>>>>I'm looking into graphics packages and I would like
>>>>to check out both Cello and OpenGL but it looks like I will be
>>>>contending with a naming conflict.
>>>
>>>The latest Cello now uses kt-opengl, so I guess your client code could
>>>use cl-opengl quite happily without conflict.
>>>
>>>
>>>>Why does Cello have it's own OpenGL bindings?
>>>
>>>I decided I really hated what they did with cl-opengl and did not convert.
>>
>>
>> What did you do differently?
>
> I did not add a fancy layer of abstraction or change the names of
> constants.
I see.
Paul Donnelly wrote:
>>> What did you do differently?
>>
>> I did not add a fancy layer of abstraction or change the names of
>> constants.
>
> I see.
cl-glfw has another opengl binding in its git. Looks a bit thinner than
cl-opengl, though I don't really know anything about it.
http://www.cliki.net/cl-glfw
Both cl-opengl and cl-glfw-opengl support opengl 2.x shaders and stuff.
I've been happy enough with cl-opengl + lispbuilder-sdl (*) for my
purposes- while cl-opengl includes a glut binding, it doesn't mandate
its use.
cl-opengl's "fancy layer of abstraction" has IMO proven its worth when
I've been doing opengl stuff incrementally at the repl. I dunno if it
has performance implications to speak of, but I haven't hit them
yet.
* The following magic line helps a lot with that particular combo:
(setf cl-opengl-bindings:*gl-get-proc-address*
#'sdl-cffi::sdl-gl-get-proc-address)
; N.B. don't use any ext. functions which go through GetProcAddress
; until AFTER an SDL opengl surface exists (lazy loading of
; libgl I guess)