Lisp OpenGL fans rejoice. The GLUT has been hacked to play well with
interactive development:
http://www-users.york.ac.uk/~rpf1/glut.html
I hope I am not jumping the gun here, but I /am/ getting away with
running again and again and closing windows without them taking out the
whole IDE.
When I get a little hello-world going I'll put together a little package
and put it on-line. It'll be CL, UFFI, and OpenGL+GLUT. Lotsa
universality, there.
One big gotcha might be declaring foreign callbacks, I did not see that
in UFFI--does every CL offer that?
Anyway, getting ahead of myself, just wanted to let any 3D fans out
there know the GLUT looks like it is open for interactive, dynamic
development.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
On Sat, Dec 07, 2002 at 05:40:30PM +0000, Kenny Tilton wrote:
> One big gotcha might be declaring foreign callbacks, I did not see that
> in UFFI--does every CL offer that?
'fraid not, particularly CMUCL and SBCL. One reason I've avoided GLUT.
> Anyway, getting ahead of myself, just wanted to let any 3D fans out
> there know the GLUT looks like it is open for interactive, dynamic
> development.
Well, the package you point to has some problems,
(a) it's not open-source and has only Windows libraries
(b) I do not know what code source it is based on
Freeglut seems more viable, has freely available source which can
probably be hacked up similarly if it hasn't been already, and seems to
have some active support. The problem is that it is advertised as
``alpha'' and only supports Win32 and Linux.
http://freeglut.sf.net/
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Sat, Dec 07, 2002 at 05:40:30PM +0000, Kenny Tilton wrote:
>
>>One big gotcha might be declaring foreign callbacks, I did not see that
>>in UFFI--does every CL offer that?
>
>
> 'fraid not, particularly CMUCL and SBCL. One reason I've avoided GLUT.
Pity. Well, we could hack the glut to send OS application events to the
calling process, let the OS provide the glue. Something like that.
> Well, the package you point to has some problems,
> (a) it's not open-source and has only Windows libraries
re windows-only: oops, I should have mentioned that, but to me the key
was the proof-of-concept. I eventually found the source, but before then
(and even now, perhaps) my thougt was to go ahead and rehack myself.
famaous last words: it's not that big a deal.
re not open: right, my use for the GLUT is simply as a bridge to a
universal CL GUI I can share with other developers to get them stoked
about a project in which the GLUT would eventually be replaced.
> (b) I do not know what code source it is based on
GLUT 3.7, as far as I can make out
>
> Freeglut seems more viable, has freely available source which can
> probably be hacked up similarly if it hasn't been already, and seems to
> have some active support.
thx for the lead. I see jan 2002 as the last release, not too bad at
all. Maybe that's the replacement. :)
The problem is that it is advertised as
> ``alpha'' and only supports Win32 and Linux.
heh-heh, well if we cannot get Mark K to "give up" GLUT and we have to
reinvent the wheel, at least the glass is two-thirds full. I see Apple
has a GLUT for OS X. Installing the dev tools now. I wonder if they
ported or wrote their own? probably ported.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
On Sat, 07 Dec 2002 13:26:39 -0500, Matthew Danish wrote:
> Well, the package you point to has some problems, (a) it's not
> open-source and has only Windows libraries (b) I do not know what code
> source it is based on
>
> Freeglut seems more viable, has freely available source which can
> probably be hacked up similarly if it hasn't been already, and seems to
> have some active support. The problem is that it is advertised as
> ``alpha'' and only supports Win32 and Linux.
>
> http://freeglut.sf.net/
freeglut would probably be easy to put on other unixs with X11 support.
I might try testing out that claim by installing Mesa on one of my Suns,
but I don't have the time for that now.
However, glut generally sucks, and freeglut is only slightly better.
There are other nearly as simple toolkits out there that one can use with
less trouble.
On Sun, Dec 08, 2002 at 07:37:44AM +0000, Joshua D. Boyd wrote:
> However, glut generally sucks, and freeglut is only slightly better.
> There are other nearly as simple toolkits out there that one can use with
> less trouble.
I agree with you, see [1]. But Kenny wants to be able to open multiple
windows which SDL doesn't currently support. Know of any better
alternatives for him?
[1] http://cl-sdl.sourceforge.net/
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Sun, Dec 08, 2002 at 07:37:44AM +0000, Joshua D. Boyd wrote:
>
>>However, glut generally sucks, and freeglut is only slightly better.
>>There are other nearly as simple toolkits out there that one can use with
>>less trouble.
I would love to hear suggestions.
>
>
> I agree with you, see [1]. But Kenny wants to be able to open multiple
> windows which SDL doesn't currently support. Know of any better
> alternatives for him?
>
> [1] http://cl-sdl.sourceforge.net/
>
(a) I do not ask a lot of the OS in the two CL application frameworks I
have built, one in MCL and one in ACL. So GLUT does not have to do much.
(2) GLUT serves well even if it is a bridge to future universal CL
window management system coded native for each of win32, macos and the
Xes, or something like SDL.
(3) I am actually in the feasibility stage. For all I know I may grow
disenchanted with the GLUT and move on.
(4) Don't forget, I already have two almost-native frameworks over here.
It's not that hard... there is usually a starter app that provides a big
headstart, and lotsa nice books to help if this project takes off.
(5) If this project doesn't take off, it won't be because of the GLUT,
it will be because mystuff sucks. So the soooner I find out, the less
effort is wasted.
(6) One Guiding Principle is that Cello should be Lisp All the Way Down.
OpenGL is an acceptable exception. But i definitely do not want any
package with it's own application framework between CL and the native
OS. I do not know the GLUT very well at all, but it seems to me doing
Just Enough to provide a universal window manager (plus some high-level
opengl goodies to make simple stuff easy). The rest is up to me, and
that is how I want it because in my frameworks Cells drive dtaaflow off
of WMS primitives like mouse motion and key presses.
Thx, for all the input, everyone.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd