c.l.l inhabitants,
Help. My supervisor thinks that there are fundamental problems with Lisp
and 3d graphics: I have no idea why he could think that, but I seem to
need counter - examples: I know of cells-gtx & the clim which are
fantastic gui's, but little of any good 3d engines: I know of sdl-opengl
bindings, and the glx component of clx, and I strongly suspect this is
yet another pernicious Lisp Myth, but these aren't actual applications I
can point to.
Does anyone have any suggestions? .
John Connors.
http://badbyteblues.blogspot.com
>From what I can tell, the biggest problem with Lisp and 3D (game)
graphics is that there is no obvious example that you can point to and
say "there, they did a fast 3D engine with Lisp, QED it can be done"
I personally only tinker with 3D graphics & I am very new to Lisp - so
what I say here will probably be quite uninformed.
Lisp execution speed:
Contrived benchmarks show that Lisp is probably slower than C, but not
by much - maybe 20%. I haven't seen benchmarks of large realworld
programs (who writes large programs twice? :) but, I think it is safe
to say that many people on c.l.l think that Lisp is actually faster
than C. So overall I don't think that execution speed should be an
issue.
Able to call a 3D API quickly:
As I understand it most common Lisps that can be compiled can directly
call C functions in libraries with no more overhead that regular C. So
OpenGL is good here, Direct3D might be a different story.
Able to maintain smooth framerates (Will GC kill me?)
I really don't know enough about CL garbage collection to make
comments here, but - I've written a small 3D engine in D (which is
garbage collected) and had no problems. The trick is simply to avoid
creating garbage at times of high interactivity. In D this was pretty
easy, because allocations are easy to track & that is the only time
that a GC can occur.
I imagine that with a couple of days of profiling and tuning GC could
be almost eliminated from an inner loop, so in my naive opinion I don't
consider GC to be an insurmountable problem.
If you do end up doing some Lisp 3D work, please post back - I'd be
interested.
Cheers
Brad
bradb wrote:
> Lisp execution speed:
> Contrived benchmarks show that Lisp is probably slower than C, but not
> by much - maybe 20%. I haven't seen benchmarks of large realworld
> programs (who writes large programs twice? :) but, I think it is safe
> to say that many people on c.l.l think that Lisp is actually faster
> than C. So overall I don't think that execution speed should be an
> issue.
Yes. Lisp is highly likely to be faster than C for complicated tasks, where
development time is more important than the constant-prefactor in the speed
because it lets you implement more algorithmic optimisations.
However, this is very task-dependent and some 3D applications (particularly
games) have relatively small speed-critical parts that basically perform
simple loops over float arrays, which is likely to be worst case for Lisp's
performance.
> Able to maintain smooth framerates (Will GC kill me?)
> I really don't know enough about CL garbage collection to make
> comments here, but - I've written a small 3D engine in D (which is
> garbage collected) and had no problems. The trick is simply to avoid
> creating garbage at times of high interactivity. In D this was pretty
> easy, because allocations are easy to track & that is the only time
> that a GC can occur.
> I imagine that with a couple of days of profiling and tuning GC could
> be almost eliminated from an inner loop, so in my naive opinion I don't
> consider GC to be an insurmountable problem.
I have had a similar experience with OCaml (it works well) provided you
don't accumulate any huge arrays of non-atomic types. However, I have no
idea if either of our experiences will carry over to Lisp. In particular,
does the language impose any relevant restrictions on what kinds of GCs can
be used by Lisp implementations?
> If you do end up doing some Lisp 3D work, please post back - I'd be
> interested.
Me too.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Pascal Bourguignon wrote:
>
> There are OpenGL FFIs for CL.
> http://www.cliki.net/admin/search?words=opengl
However, to my knowledge they are all of poor quality. Where "poor"
means not regularly maintained, and not tracking OpenGL 2.0 or even
versions as recent as 1.5. That said, for many problem domains, old
OpenGL bindings are not a barrier to OpenGL development. It does
matter a great deal if you're interested in game development, however.
Be prepared to update what's available or roll your own.
> A famous PlayStation game was developed with CL.
> http://www.franz.com/success/customer_apps/animation_graphics/
It was not developed in Common Lisp. It was developed in Game Object
Assembly Lisp (GOAL), a custom language that Franz apparently helped
them with.
> and Lush which is designed with 3D graphics in mind.
> http://lush.sourceforge.net/
Lush is a Lisp, but it is not Common Lisp. Just trying to be clear on
Common Lisp's capabilities and support, vs. all the Lisps that have
ever existed. Certainly, various Lisps have been used for 3D graphics
problems over and over again.
Cheers,
Brandon Van Every
"Cruise Director" <···········@gmail.com> writes:
> Pascal Bourguignon wrote:
>
>> A famous PlayStation game was developed with CL.
>> http://www.franz.com/success/customer_apps/animation_graphics/
>
> It was not developed in Common Lisp. It was developed in Game Object
> Assembly Lisp (GOAL), a custom language that Franz apparently helped
> them with.
Sigh. It was developed in Common Lisp. It was developed in Game Object
Assembly Lisp (GOAL), which is a domain-specific lisp-like language (you
know, the kind Lisp is best at? ... oh, perhaps not), a custom language
that Franz had nothing to do with developing and only helped them to
optimize.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
>
> Sigh. It was developed in Common Lisp. It was developed in Game Object
> Assembly Lisp (GOAL), which is a domain-specific lisp-like language (you
> know, the kind Lisp is best at? ... oh, perhaps not), a custom language
> that Franz had nothing to do with developing and only helped them to
> optimize.
Ah. That sets the record straight then. Don't sigh: none of this info
makes it to Gamasutra Postmortems, and that's what the unwashed masses
of game developers actually read. Common Lisp has received no airtime;
Lisp has, but when pressed people cite GOAL and not CL.
Cheers,
Brandon Van Every
Cruise Director wrote:
> Ah. That sets the record straight then. Don't sigh: none of this info
> makes it to Gamasutra Postmortems, and that's what the unwashed masses
> of game developers actually read. Common Lisp has received no airtime;
> Lisp has, but when pressed people cite GOAL and not CL.
From p.2 of the Gamasutra Postmortem: "Development software used:
Allegro, Common Lisp, Visual C++, Maya, Photoshop, X Emacs, Visual Slick
Edit, tcsh, Exceed, CVS"
You'd be pretty depressing if you were right more often.
Cameron MacKinnon wrote:
> Cruise Director wrote:
> > Ah. That sets the record straight then. Don't sigh: none of this info
> > makes it to Gamasutra Postmortems, and that's what the unwashed masses
> > of game developers actually read. Common Lisp has received no airtime;
> > Lisp has, but when pressed people cite GOAL and not CL.
>
> From p.2 of the Gamasutra Postmortem:
at http://www.gamasutra.com/features/20020710/white_02.htm
for those coming late to the barbeque :-)
> "Development software used:
> Allegro, Common Lisp, Visual C++, Maya, Photoshop, X Emacs, Visual Slick
> Edit, tcsh, Exceed, CVS"
Technically, I stand corrected yet again. But in practice, my point is
valid. Common Lisp is mentioned in an inset window at the very end of
the article, shoved into a list of other tools, with no supporting text
or elaboration about any of it. The odds are pretty high that nobody
reads or remembers this unless they're really, really looking for any
detail they can scrounge. Wheras GOAL is featured prominently in the
article, with 2 entire postmortem sections devoted to it. CL is not
mentioned at all.
We can hope that the unwashed think that it's all just 'Lisp'. The
problem is, once one is washed, and starts to research, then one starts
to ask more sophisticated questions like exactly what Lisp are we
talking about. Maybe by that time the linkage to CL is forgotten, if
it was noticed to begin with. I suppose the antidote is good mention
here and on Franz's website, etc., but that is not exactly traction in
the game industry.
It also doesn't help that the 2 sections are entitled "GOAL rules!" and
"GOAL sucks!" It's a mixed result, not a ringing endorsement for CL,
and the skeptical C++ crowd are going to remember 'sucks' more than
'rules'.
> You'd be pretty depressing if you were right more often.
I think I'm far more right than wrong on this one. For instance, show
me any other commercial Lisp or Scheme game.
Cheers,
Brandon Van Every
Taking risk where others will not.
Ingvar wrote:
> "Cruise Director" <···········@gmail.com> writes:
> >
> > Common Lisp has received no airtime;
> > Lisp has, but when pressed people cite GOAL and not CL.
>
> It bloody well did! I read that post mortem and that is *exactly* the
> image the post mortem gave me. That you (or anyone else) didn't grasp
> taht is no fault of Naughty Dog's (well, possibly, they wrote the post
> mortem, after all).
Were you fully versed in Common Lisp before you read the article? If
so, that would explain why you think it's clear. Try to imagine how
the following paragraph reads if you don't know anything about Lisp:
"5. GOAL rules! Practically all of the run-time code (approximately
half a million lines of source code) was written in GOAL (Game Object
Assembly Lisp), Naughty Dog's own internally developed language, which
was based on the Lisp programming language. "
To a naive reader, this sounds like they started with Lisp and built
something different. Rather much like I might start with C and arrive
at Object C. The idea of using macros to create domain specific
languages is not explained.
Also consider statements like:
"Compared to the thousands of programmers with many years of C++
experience, there are relatively few programmers with Lisp experience,
and no programmers (outside of Naughty Dog) with GOAL experience,
making hiring more difficult."
This definitely makes it sound like GOAL is a different beast than
Lisp.
Cheers,
Brandon Van Every
Ingvar wrote:
> "Cruise Director" <···········@gmail.com> writes:
> >
> > This definitely makes it sound like GOAL is a different beast than
> > Lisp.
>
> Well, LOOP is a different beast than FORMAT. GLSL is a different beast
> from C or C++. But...
Complicating matters further, GOAL is not open source. It is Naughty
Dog private homespun. So, nobody downloads GOAL to assess its
implementation strategy. Nobody learns that it's really a pile of CL
macros. The unwashed C++ crowd doesn't grab Lisp manuals to learn Lisp
theory; they grab implementations, inspect them, and see if they build.
Nothing to grab, then nothing to learn. Ergo, to the unwashed, GOAL
is simply some custom language that Naughty Dog cooked up, which has
something to do with Lisp, which is rumored to be an unpleasant
language "because of parentheses." Nothing about the postmortem breaks
these perceptions, as the "GOAL sucks!" sections decries the foibles of
1 guy working on some new compiler for a year. I mean, if it was
really just off-the-shelf CL, why did it take them a year?
Proper marketing campaings, with well thought out messages for the
unwashed C++ crowd, *can* be devised. They were not ideally devised in
the case of GOAL, and consequently there is not much benefit to CL
accrueing from it. It's easy for knowledgeable Lisp techies to second
guess the impressions of the unwashed, substituting their own
impressions. But this isn't good marketing skill; you have to put
yourself in the shoes of the moron evaluating the product. The message
that the game industry is waiting for is clear enough: "X rules! X
made us money!" No qualifications or excuses. No "What Went Wrong."
So, I continue to plod along with such a vision, as I haven't lost
faith in it just yet. But it is a difficult task and my faith is
sorely tested. Within a few weeks I'll either have Chicken Scheme
doing what I want, or I'll be chucking it and starting from scratch in
pure ASM. I simply don't have time for week after week of broken open
source Windows tools anymore. That's a good recipe for staying
indefinitely poor.
Cheers,
Brandon Van Every
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Cruise Director wrote:
> Proper marketing campaings, with well thought out messages for the
> unwashed C++ crowd, *can* be devised. They were not ideally devised in
> the case of GOAL, and consequently there is not much benefit to CL
> accrueing from it.
Why on earth would Naughty Dog have wanted to give away the basis of
their competitive advantage other game developers? GOAL was never a product.
Luke J Crook wrote:
> Cruise Director wrote:
> > Proper marketing campaings, with well thought out messages for the
> > unwashed C++ crowd, *can* be devised. They were not ideally devised in
> > the case of GOAL, and consequently there is not much benefit to CL
> > accrueing from it.
>
> Why on earth would Naughty Dog have wanted to give away the basis of
> their competitive advantage other game developers? GOAL was never a product.
They wouldn't. It wasn't. Consequently, GOAL isn't exactly the
greatest advertizement for Common Lisp. I think we agree here, but I'm
putting a different emphasis on it.
As far as the game industry is concerned, GOAL is a unique programming
language. From a tools perspective that's entirely fair: it took them
1 year to develop a compiler for it. It's actually a pretty typical
Postmortem saga: Yet Another Scripting Language. Some genius realizes
he's getting paid to advance his own career, so he spends this huuuuuge
amount of time on personally aggrandizing R&D that isn't really of
direct benefit to the game development pipeline. People can't just
take scripting languages off-the-shelf because that's not career
aggrandizing enough. Well, actually people can, but you don't hear
about it in their Postmortems 'cuz it doesn't create death and mayhem.
Actually, to be fair Naughty Dog got a 50/50 result, so they're a class
better than the legions of fools who have completely killed their game
projects inventing basic technology from scratch. The game industry
will really make you shake your head. We can only hope that once
people read hundreds of Postmortems, the seeds of change will be sown
and the powers-that-be will finally get a clue.
Cheers,
Brandon Van Every
Cruise Director wrote:
> As far as the game industry is concerned, GOAL is a unique programming
> language. From a tools perspective that's entirely fair: it took them
> 1 year to develop a compiler for it. It's actually a pretty typical
> Postmortem saga: Yet Another Scripting Language. Some genius realizes
> he's getting paid to advance his own career, so he spends this huuuuuge
> amount of time on personally aggrandizing R&D that isn't really of
> direct benefit to the game development pipeline.
To me that sounds merely like another bad management case. If you allow
developers to do toy stuff that isn't exactly necessary for the project,
that's probably taking too much resources. For something like a game
company, language issues clearly should be outsourced to some degree
(maybe just buying into one of many open-source implementations and
enhancing that).
--
The road to hell is paved with good intentions.
This is just my guess, but there might have been a
reason other than the developer's ego.
They must have started developing GOAL when PS2
was just out, or even before. If you were in it,
you remember how the situation was; the toolchain
was buggy, support libraries were scarce, and
there were few third party solutions. Every game
developer that started early days of PS2 must have
put quite a lot of effort in developing in-house
tools and libraries. I myself wrote a kind of
parameterized assembler for VU. I imagine not a
few people had the same problem of 'waiting for
in-house tools to be fixed' to a certain degree.
I attended a session in GDC2002 where a guy from
Naughty Dog talked about PS2 memory architecture
in great details ("accessing memory in a certain
pattern requires one extra cycle" or that kind of
stuff) and how they exploited it. I got an
impression that having in-house compiler would
have helped them to do such tweaking.
> Within a few weeks I'll either have Chicken Scheme
> doing what I want, or I'll be chucking it and starting from scratch in
> pure ASM.
Haha! Are you serious? I think that it is pretty much a fool's errand
to write anything* in ASM these days, and it will certainly be slower
going than Lisp/Scheme.
Brad
* Exceptions that spring to mind are
- bootloaders
- machine specific operations
- certain emulations, like software floating point
- some inner loops as the last resort
bradb wrote:
> > Within a few weeks I'll either have Chicken Scheme
> > doing what I want, or I'll be chucking it and starting from scratch in
> > pure ASM.
>
> Haha! Are you serious? I think that it is pretty much a fool's errand
> to write anything* in ASM these days, and it will certainly be slower
> going than Lisp/Scheme.
Skilled ASM junkies almost always beat the speed of any compiler's
code. This is assuming they're skilled enough to know what requires an
algorithmic solution, what requires a "speed of light" ASM solution,
how to profile, what profiling does and doesn't tell you, etc. My
career experience is in this skillset. I was doing 64-bit DEC Alpha
coding in 1996; I quit in 1998 and have been waiting for the rest of
the industry to catch up since then. To date, ASM is the only language
that I actually like, and the only one that I'm proven to be gifted at.
I'm sure this comes from a childhood of learning binary arithmetic in
6th grade, PEEKs and POKEs in a 64K Atari 800 memory map, etc. I do I
think I'm capable of other great things, but I haven't moved on to the
right language + toolchain yet. I'm ok at C++, but it's a dogshit
language with no scope for elan, unless you're kinky and into serious
pain.
Of course it usually takes longer to write ASM code than higher level
language code. That's the price the ASM crowd pays for performance,
and it's why big software systems are not written in ASM anymore. In
designing a language, I would start from ASM and add more abstract
capabilities as the need arises. To this end, my broad survey of
programming languages over the past 2 years won't have been a waste of
time. Also it is worth knowing that there's an academic branch of
so-called Typed Assembly Language, and also pragmatic branches such as
High Level Assembly. So, this ain't necessarily your father's ASM.
Cheers,
Brandon Van Every
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Cruise Director wrote:
> Skilled ASM junkies almost always beat the speed of any compiler's
> code.
I really don't think that has been true for a very long time. As long
as you don't have a totally braindead compiler, the actual instructions
executed are unlikely to get you much performance increase - tuning the
cache hits and misses will do much better for your speed. If you are
able squeeze a bit more out of assembler than C - then it is such a
fraction of a percent that it probably won't matter.
I started to write about why I think this, but realised that this is a
Lisp list, not an assembler list & I could be writing code instead.
If you think that assembly is a better language, well use it & more
power to you :)
Brad
bradb wrote:
> Cruise Director wrote:
> > Skilled ASM junkies almost always beat the speed of any compiler's
> > code.
>
> I really don't think that has been true for a very long time.
Then you are not a skilled ASM junkie. ASM is a specialist skill that
never dies, because compiler writers can't keep up with new CPUs. If
we used the same CPU architecture for 10 years then yes, what you claim
would have a chance of becoming true. But that's not how companies
like Intel do business.
> As long
> as you don't have a totally braindead compiler, the actual instructions
> executed are unlikely to get you much performance increase - tuning the
> cache hits and misses will do much better for your speed.
Cache prefetch instructions are still ASM instructions.
> If you are
> able squeeze a bit more out of assembler than C - then it is such a
> fraction of a percent that it probably won't matter.
This mantra is inaccurate and tiring. The standard engineering answer
applies here: "It Depends." I agree that you have to be careful - not
every piece of code is locally optimizeable. It may take a global code
rearrangement to set up an architecture where local ASM can be best
advantaged. Put another way, ASM in a vacuum is not very useful.
There's an ecology of algorithm, C precursor, and ASM that needs to be
dealt with in unison.
> I started to write about why I think this, but realised that this is a
> Lisp list, not an assembler list & I could be writing code instead.
> If you think that assembly is a better language, well use it & more
> power to you :)
You could always go argue about compiler vs. ASM performance in
comp.lang.asm.x86. Or just read the archives, as it's been debated to
death. I myself don't feel a need to; I know what's what.
Cheers,
Brandon Van Every
In article <························@g49g2000cwa.googlegroups.com>,
bradb <··············@gmail.com> wrote:
...
> tuning the
>cache hits and misses will do much better for your speed.
This should be shouted from the rooftops.
I didn't quite realize how much this mattered until I ran a little
experiment with memory access patterns. I was able to get 30-40x
better performance doing linear memory access compared with random memory
access.
-Mike
--
http://www.mschaef.com
bradb wrote:
> Cruise Director wrote:
>> Skilled ASM junkies almost always beat the speed of any compiler's
>> code.
> I really don't think that has been true for a very long time. As long
> as you don't have a totally braindead compiler, the actual instructions
> executed are unlikely to get you much performance increase - tuning the
> cache hits and misses will do much better for your speed. If you are
Sure, cache is *very* important, but just look at typical GCC output on
x86 or PPC to see how much it still sucks. Ok, maybe that IS a
braindead compiler, following a braindead ABI.
> able squeeze a bit more out of assembler than C - then it is such a
> fraction of a percent that it probably won't matter.
For very small functions the difference is quite noticeable, even when I
still follow calling conventions on PPC, but for the typical chunk of C
code it doesn't matter, that's right.
Of course any code that'd get anything done would employ lots of short
higher-order closures, if those weren't a PITA to type in C.
> I started to write about why I think this, but realised that this is a
> Lisp list, not an assembler list & I could be writing code instead.
> If you think that assembly is a better language, well use it & more
> power to you :)
Somebody on c.l.scheme just posted an x86 assembler in Scheme. Sounds
like an ideal target for macro expansion or compiler backends (if you
don't want to build on top of Lisp).
--
The road to hell is paved with good intentions.
Brandon
Why don't you talk Lisp to engine instead directly to OpenGL/
DirectX lib
if you don't like Verrazano ( And i really want't to know why)?
Putting some c functions wrappers in a DLL is not that hard and
if you avoid moving classes between C++ and Lisp simple C FFI will do.
And BTW if you don't want to invest at least 1100$ in LW I'm really
curious how do you plan to make your meshes look any descent ? You're
modeller also?
Besides you don't have to pay for commercial Allegro/LW right now ,
make something
really great and then ask for funding from the publisher ?
Hey if you have next GTA in Lisp you can ask Duane Rettig to help you
make some deal with Franz to get runtime without fees and pay them some
percentage instead?
Anyway you get many options so stop whining and start coding 'couse
your game won't write itself .
cheers
Bobi
"Cruise Director" <···········@gmail.com> writes:
> Duane Rettig wrote:
>>
>> Sigh. It was developed in Common Lisp. It was developed in Game Object
>> Assembly Lisp (GOAL), which is a domain-specific lisp-like language (you
>> know, the kind Lisp is best at? ... oh, perhaps not), a custom language
>> that Franz had nothing to do with developing and only helped them to
>> optimize.
>
> ... Don't sigh: ...
I sigh because I don't like repeating myself. Googling for
Naughtydog on this newsgroup easily finds the kind of information
that you did not bother looking for:
http://groups.google.com/group/comp.lang.lisp/msg/ea2bc39b38a3f3de
http://groups.google.com/group/comp.lang.lisp/msg/7648a76abc00078c
I sigh because I once made the mistake of considering with an open
mind the possibility that you are not a troll:
http://groups.google.com/group/comp.lang.lisp/msg/9a872d02a12fcb40
I will not make that mistake again.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Cruise Director wrote:
> Pascal Bourguignon wrote:
>>
>> There are OpenGL FFIs for CL.
>> http://www.cliki.net/admin/search?words=opengl
>
> However, to my knowledge they are all of poor quality. Where "poor"
> means not regularly maintained, and not tracking OpenGL 2.0 or even
> versions as recent as 1.5. That said, for many problem domains, old
> OpenGL bindings are not a barrier to OpenGL development. It does
> matter a great deal if you're interested in game development, however.
> Be prepared to update what's available or roll your own.
Are any of the existing bindings safe?
>> A famous PlayStation game was developed with CL.
>> http://www.franz.com/success/customer_apps/animation_graphics/
>
> It was not developed in Common Lisp. It was developed in Game Object
> Assembly Lisp (GOAL), a custom language that Franz apparently helped
> them with.
What are the odds that game companies leverage such things for publicity,
i.e. that the embedded Lisps bear little resemblance to CL? Are the
implementations available?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Cruise Director wrote:
> > Pascal Bourguignon wrote:
> >>
> >> There are OpenGL FFIs for CL.
> >> http://www.cliki.net/admin/search?words=opengl
> >
> > However, to my knowledge they are all of poor quality. Where "poor"
> > means not regularly maintained, and not tracking OpenGL 2.0 or even
> > versions as recent as 1.5. That said, for many problem domains, old
> > OpenGL bindings are not a barrier to OpenGL development. It does
> > matter a great deal if you're interested in game development, however.
> > Be prepared to update what's available or roll your own.
>
> Are any of the existing bindings safe?
I can't speak for the expensive commercial Lisps like Franz and
Lispworks. I do know that in open source land, I have not found a
viable Lisp + OpenGL toolchain. I have posted on the subject of
canonical OpenGL bindings several times in both c.l.l and c.l.s. My
working assumption is that I have to build such a canonical binding,
prove that it works, and then get other people to use it. If I
continue on my current trajectory, I doubt I'll arrive at the "get
other people to use it" stage until sometime late next year.
Also I'm still gunning with Chicken Scheme for now. In that arena, I'm
working on a much more basic problem of getting it to build reliably on
Windows. Into the breach we've thrown CMake, which offers the
potential of much better cross-platform support than the GNU Autotools
toolchain. http://www.cmake.org Chicken's use of CMake is still
experimental, however. Right now it doesn't build.
> >> A famous PlayStation game was developed with CL.
> >> http://www.franz.com/success/customer_apps/animation_graphics/
> >
> > It was not developed in Common Lisp. It was developed in Game Object
> > Assembly Lisp (GOAL), a custom language that Franz apparently helped
> > them with.
>
> What are the odds that game companies leverage such things for publicity,
> i.e. that the embedded Lisps bear little resemblance to CL? Are the
> implementations available?
I don't even think it's fair to use a plural here. To my knowledge,
the only game company that has made public note of anything Lisp-like
is Naughty Dog, with their GOAL as mentioned above. It merely serves
as proof-of-concept that Lisp or Scheme can be useful in game
development. It is certainly not a game industry trend. As far as I
can tell, 3D game guys don't know how to do anything other than C++.
Well, they know Python, Lua, and Ruby, but I'm talking about higher
performance HLLs. C++ is deeply, deeply entrenched, and it takes a
complete maverick such as myself to try to cough out a usable
alternative toolchain.
For all the stones that people have thrown at me over the past 2 years,
I've seen no evidence whatsoever that anyone else is taking the HLL
commercial Windows game development problem seriously. No I haven't
gotten it done; show me anyone who has, or who has even vaguely stuck
with it. My detractors think that things like getting tools and builds
to work is free and easy. Clearly, they don't actually do any
development on Windows, they have no idea how shoddy things really are.
Cheers,
Brandon Van Every
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Cruise Director wrote:
> Pascal Bourguignon wrote:
> >
> > There are OpenGL FFIs for CL.
> > http://www.cliki.net/admin/search?words=opengl
>
> However, to my knowledge they are all of poor quality. Where "poor"
> means not regularly maintained, and not tracking OpenGL 2.0 or even
> versions as recent as 1.5. That said, for many problem domains, old
> OpenGL bindings are not a barrier to OpenGL development. It does
> matter a great deal if you're interested in game development, however.
> Be prepared to update what's available or roll your own.
>
Old OpenGL bindings are still completely valid. The routines do not
change between versions. It is trivial to add additional bindings. Grab
a set of bindings and the OpenGL spec and follow the form of the
existing bindings to add what you need.
I am doing this with my game code, adding Lispworks FFI bindings for
newer OpenGL routines as I have need for them. It takes less than a
minute to add one.
Brad Might wrote:
> Cruise Director wrote:
> > Pascal Bourguignon wrote:
> > >
> > > There are OpenGL FFIs for CL.
> > > http://www.cliki.net/admin/search?words=opengl
> >
> > However, to my knowledge they are all of poor quality. Where "poor"
> > means not regularly maintained, and not tracking OpenGL 2.0 or even
> > versions as recent as 1.5. That said, for many problem domains, old
> > OpenGL bindings are not a barrier to OpenGL development. It does
> > matter a great deal if you're interested in game development, however.
> > Be prepared to update what's available or roll your own.
> >
>
> Old OpenGL bindings are still completely valid. The routines do not
> change between versions.
Doesn't help when you want to use OpenGL 2.0 features, particularly
GLSL. Also, querying for function call pointers is a PITA. One of my
goals is to build something like Glee or Glew so that the "which
OpenGL?" problems go away.
http://elf-stone.com/glee.php
http://glew.sourceforge.net/
Why not just use Glee or Glew themselves, you may ask? Well, Glew is
mostly LPGL, but some of the generator code is GPL and I don't like
that. Glee is MIT licensed, and so that's where I'll be starting from,
but there may be a cleaner way to do things under Scheme. Time will
tell.
> It is trivial to add additional bindings.
In an industrial sense, the hell it is. Evidence: a complete,
well-tested, production quality set of up-to-date OpenGL bindings is
simply never done. Other languages get it done, but Lisp and Scheme
don't. What you're saying is sure, every single teensy weensy step
along the way is easy to do, as long as you've got 100 hours to do it.
Then a few years down the road all the software breaks because
something has bitrotted. Nobody can port anything because each FFI is
different, so the support across multiple Lisps and Schemes doesn't
happen....
The endgame is almost nobody uses Lisp or Scheme for commercial games,
because the level of industrialization cannot be taken seriously. So
then there's this chicken-and-egg of lack of energy going into 3D
improvement in Lisp / Scheme land. Things remain as they are because
people like you think that cottage industry "code one more line at a
time" is sufficient.
Cheers,
Brandon Van Every
I won't spend more than 1 day configuring 1 thing.
Cruise Director wrote:
> In an industrial sense, the hell it is. Evidence: a complete,
> well-tested, production quality set of up-to-date OpenGL bindings is
> simply never done. Other languages get it done, but Lisp and Scheme
> don't. What you're saying is sure, every single teensy weensy step
> along the way is easy to do, as long as you've got 100 hours to do it.
Gauche has GL bindings including GLSL support (and partial binding to
Cg).
http://practical-scheme.net/gauche/
I don't claim it "well-tested, production quality", though I
did used it for prototying certain new game ideas for a
commercial production.
The thing is, a commercial game is a patchwork of various
modules, especially when networking is involved. Even if I can
make some Scheme code sneak into the final product, it won't
be something that I can advertise with bells and whistles.
Cruise Director wrote:
> In an industrial sense, the hell it is. Evidence: a complete,
> well-tested, production quality set of up-to-date OpenGL bindings is
> simply never done. Other languages get it done, but Lisp and Scheme
> don't.
Games are the inverse of 'production quality' software.
Luke J Crook wrote:
> Cruise Director wrote:
>
> > In an industrial sense, the hell it is. Evidence: a complete,
> > well-tested, production quality set of up-to-date OpenGL bindings is
> > simply never done. Other languages get it done, but Lisp and Scheme
> > don't.
>
> Games are the inverse of 'production quality' software.
Well, at the level of basic support libraries, which is what we're
talking about here, that's just not a relevant or valid statement.
Cheers,
Brandon Van Every
Cruise Director wrote:
> Brad Might wrote:
> > Cruise Director wrote:
> > Old OpenGL bindings are still completely valid. The routines do not
> > change between versions.
>
> Doesn't help when you want to use OpenGL 2.0 features, particularly
> GLSL. Also, querying for function call pointers is a PITA. One of my
> Other languages get it done, but Lisp and Scheme
> don't. What you're saying is sure, every single teensy weensy step
> along the way is easy to do, as long as you've got 100 hours to do it.
> Then a few years down the road all the software breaks because
> something has bitrotted. Nobody can port anything because each FFI is
> different, so the support across multiple Lisps and Schemes doesn't
> happen....
>
> The endgame is almost nobody uses Lisp or Scheme for commercial games,
> because the level of industrialization cannot be taken seriously. So
> then there's this chicken-and-egg of lack of energy going into 3D
> improvement in Lisp / Scheme land. Things remain as they are because
> people like you think that cottage industry "code one more line at a
> time" is sufficient.
>
>
> Cheers,
> Brandon Van Every
I don't think that a single set of universal OpenGL bindings for every
Common Lisp would make a bit of difference in the adoption rate.
I'm getting things done. The lack doesn't stop me. I add the few
additonal OpenGL bindings I need as the need arises. I haven't added
access to GLSL yet but I will do it soon, once I can get back on the
project as I want to be able to write vertex programs to support
animation on the GPU.
I'll let you know how it goes.
If you care that much about it, and are more interested in its
existence than decrying the lack of it, you could probably punch out a
first version of your universal OpenGL 2.0 bindings in less than a
week. At that point you might be able to convince some of the community
to give it some testing. In the amount of time you have spent
convincing us that it is a fatal flaw, you could have already completed
it and received glorious praise for your efforts.
Brad Might wrote:
>
> If you care that much about it, and are more interested in its
> existence than decrying the lack of it, you could probably punch out a
> first version of your universal OpenGL 2.0 bindings in less than a
> week. At that point you might be able to convince some of the community
> to give it some testing. In the amount of time you have spent
> convincing us that it is a fatal flaw, you could have already completed
> it and received glorious praise for your efforts.
I get really tired of armchair generals who spout such gobbledygook.
You clearly have done nothing to address such problems, to think this.
Nor can you probably even formulate what the problems are. You are
most likely a typical non-commercial computer guy who just talks out
his ass about how little time it takes to get things done. I think the
rule of thumb is to multiply such people's time estimates by 4x. A
real expert, by 2x. Anyways, I continue to plod along with the
realities of tools and APIs that are either not production quality or
not really portable.
I should probably refrain from wasting my time arguing with people who
don't know what production realities are.
At least since someone made a plea for help, I've given an outline of
the status quo. Lisp is very much proven in 3D graphics, much moreso
over its history than any of the other HLLs. But no, as of today, it
is not production quality. I think it's fair to say that Lisp had its
3D glory in the past, and that only big, unique codebases are carrying
that legacy forwards today. Commodity production tools for 3D just
aren't out there in open source land; people will have to either build
them or buy them.
Cheers,
Brandon Van Every
Cruise Director wrote:
> I get really tired of armchair generals who spout such gobbledygook.
> ...
> I should probably refrain from wasting my time arguing with people who
> don't know what production realities are.
(1) Wowsers
(2) Pot. Kettle. Black.
Cruise Director wrote:
> Brad Might wrote:
> >
> > If you care that much about it, and are more interested in its
> > existence than decrying the lack of it, you could probably punch out a
> > first version of your universal OpenGL 2.0 bindings
>
> I get really tired of armchair generals who spout such gobbledygook.
> You clearly have done nothing to address such problems, to think this.
> Nor can you probably even formulate what the problems are. You are
> most likely a typical non-commercial computer guy who just talks out
> his ass about how little time it takes to get things done. I think the
> rule of thumb is to multiply such people's time estimates by 4x. A
> real expert, by 2x. Anyways, I continue to plod along with the
> realities of tools and APIs that are either not production quality or
> not really portable.
>
> I should probably refrain from wasting my time arguing with people who
> don't know what production realities are.
Sorry to disappoint you Brandon but I have been <a
href="http://www.might.com/stuff/Brad Might Resume.pdf">continuously
employed as a software developer since January 1983</a> and I do know
what I'm talking about.
During the years you have spent bitching about not having the proper
tools to do game development I have been building a game using open
source (CMUCL/SBCL) and proprietary (Lispworks) Common Lisp systems. I
have created and augmented OpenGL bindings for both platforms.
Given the now availability of Verrazano as Andras suggests, you should
be able to have a baseline done in anywhere from a few minutes to a day
(depending upon any parsing issues), and then its a matter of grunt
work to sort the rest of it out and write some cross platform test
programs.
Exhaustive testing would take much longer, but is that really needed to
get off the ground? No, i don't think so.
Brad Might wrote:
>
> Given the now availability of Verrazano as Andras suggests, you should
> be able to have a baseline done in anywhere from a few minutes to a day
> (depending upon any parsing issues), and then its a matter of grunt
> work to sort the rest of it out and write some cross platform test
> programs.
Maybe, maybe not. Verrazano is pretty recent, and to me represents
risk. It's encouraging that the homepage
http://common-lisp.net/project/fetter/ claims that OpenGL works, but
YMMV for what "works" means. I will continue on my Chicken Scheme
trajectory for now, which has already been talking to C++ to some
degree for quite some time, and can certainly handle C. But if that
doesn't work out, then I'll see what Verrazano can / can't do. For my
purposes, it had better work with Corman Lisp or that's a dealbreaker.
I'm not aware of any other good + cheap Lisps on Windows, where "good"
means native compiled and performance oriented. Scheme has more
options, and Chicken Scheme in particular is BSD licensed.
> Exhaustive testing would take much longer, but is that really needed to
> get off the ground? No, i don't think so.
If you want to make some task breakdowns and accurate time estimates
for what you think is entailed - never mind the scope of what I think
is entailed - then we could discuss this seriously. But I can't take
people who say, "You can do that in a week!" seriously.
Cheers,
Brandon Van Every
Cruise Director wrote:
> But if that
> doesn't work out, then I'll see what Verrazano can / can't do. For my
> purposes, it had better work with Corman Lisp or that's a dealbreaker.
> I'm not aware of any other good + cheap Lisps on Windows, where "good"
> means native compiled and performance oriented.
Actually, "good" probably means more than that. Every time I do a
Windows Lisp investigation, my requirements are slightly different.
It's easy to forget what assumptions were made on an earlier run, so
generally I have to recheck them. Last time around, I dismissed GNU
Common Lisp due to lack of UFFI support, IIRC. Also I think Slime
didn't support it, although it turns out I don't care about Slime now.
Embedded Common Lisp, hm, I might have to revisit that one. But of
course, all of these are predicated on what actually works with
Verrazano. The vast majority of open source toolchains are not plug
and play, and on Windows they're usually broken.
Cheers,
Brandon Van Every
Cruise Director wrote:
> Cruise Director wrote:
>
> Last time around, I dismissed GNU
> Common Lisp due to lack of UFFI support, IIRC. Also I think Slime
> didn't support it, although it turns out I don't care about Slime now.
And why don't you care about slime? Slime is simply the glue between
Emacs and a Lisp environment. Slime != UFFI/CFFI/FLI/FFI etc.
> Embedded Common Lisp, hm, I might have to revisit that one. But of
> course, all of these are predicated on what actually works with
> Verrazano. The vast majority of open source toolchains are not plug
> and play, and on Windows they're usually broken.
And now suddenly you have decided that Verranzo must work for your
purposes or you will again throw in the towel?
Good grief.
A while back I downloaded the latest OpenGL header files from Mesa, ran
these through the Corman Lisp C->Lisp parser and, after a copy of
tweaks, had complete OpenGL 1.5 bindings for Corman Lisp a couple of
hours. I must be a real manly man.
I then converted the header files for OpenRM, CalCD, ODE, SDL, SDL_mixer
and SDL_gfx. Up to date bindings for these libraries for Corman Lisp.
Wow^16. Men want to be me, women want to be with me.
Luke J Crook wrote:
> Cruise Director wrote:
> > Cruise Director wrote:
> >
> > Last time around, I dismissed GNU
> > Common Lisp due to lack of UFFI support, IIRC. Also I think Slime
> > didn't support it, although it turns out I don't care about Slime now.
>
> And why don't you care about slime? Slime is simply the glue between
> Emacs and a Lisp environment. Slime != UFFI/CFFI/FLI/FFI etc.
I suppose my antecedant was weak; "it" referred to GCL, not UFFI. To
rephrase: GCL supported neither UFFI nor Slime, so that was 2 strikes
against it.
The reason I don't care about Slime is because I hate Emacs. I ain't
gonna do it; I settled that issue a month or two ago. I'd sooner write
my own editor from scratch than deal with Emacs. That's drastic; more
likely I'd bang on an open source editor that's more to my liking. My
jury's out on how advantageous or painful I think Eclipse is, but I do
like it better than Emacs.
> > Embedded Common Lisp, hm, I might have to revisit that one. But of
> > course, all of these are predicated on what actually works with
> > Verrazano. The vast majority of open source toolchains are not plug
> > and play, and on Windows they're usually broken.
>
> And now suddenly you have decided that Verranzo must work for your
> purposes or you will again throw in the towel?
Uncertain. We *were* dicussing Verranzo, and for me to bother with
that, yes it would have to work on Corman Lisp.
> Good grief.
>
> A while back I downloaded the latest OpenGL header files from Mesa, ran
> these through the Corman Lisp C->Lisp parser and, after a copy of
> tweaks, had complete OpenGL 1.5 bindings for Corman Lisp a couple of
> hours. I must be a real manly man.
>
> I then converted the header files for OpenRM, CalCD, ODE, SDL, SDL_mixer
> and SDL_gfx. Up to date bindings for these libraries for Corman Lisp.
> Wow^16. Men want to be me, women want to be with me.
Yes I recall someone's positive field report. Maybe it was you. But I
am still committed to Chicken Scheme at the moment and not interested
in changing direction. Requirements are slightly different now though.
This guy's Maya project I thought I'd be working on looks like
vaporware. Meanwhile I'm thinking about Playstation 3 ports. Corman
Lisp is not directly useful for that. And if Verranzo doesn't work
with Corman, and I had to do Corman-specific FFI stuff to get OpenGL
going, that would be a dealbreaker. But, it'll be quite some time
before I have a PS3 devkit, so this might be too much cart before the
horse. Nevertheless, the advantages of an open source BSD licensed
language are important to me.
Ok, I've decided that even though answering the OP's Plea For 3D Help
is a worthy cause, as are logos and marketing efforts, Usenet is not a
useful venue for tackling these problems. Vanishing yet again. I
bet you guys have no idea how long I typically disappaear for.
Cheers,
Brandon Van Every
Bill Atkins wrote:
> http://groups.google.com/group/comp.lang.lisp/msg/3e4b59525ac0cf8c
Signature gathering ended Monday Nov. 7th, BTW. We got 2x the number
of signatures required to Keep The Strip Clubs Sexy! This week I
weighed in on 3D and logo issues. Now it's Friday, and I'm weighing
out.
Cheers,
Brandon Van Every
Cruise Director wrote:
> For my
> purposes, it had better work with Corman Lisp or that's a dealbreaker.
> I'm not aware of any other good + cheap Lisps on Windows, where "good"
> means native compiled and performance oriented.
Here's a quick product evaluation: Please note that I own Corman and
like it for what it provides.
clisp: Byte-code interpreted = 0
Corman: Native compiled = 1
clisp: Runs on just about any platform = 1
Corman: Windows only = 0
clisp: Fast interpreted code (arithmetic calculations) = 0
Corman: The slowest natively compiled Lisp = 0
clisp: Very active user community = 1
Corman: User community not active at all = 0
clisp: Close to being ANSI Common Lisp compliant = 1
Corman: Not so much = 0
clisp: Bindings to lots of libraries, ASDF support etc. = 1
Corman: Bindings to a lot less libraries due to a lack of proper
UFFI/CFFI support = 0
clisp: Good slime<->Emacs integration = 1
Corman: Slime works, but many features - specifically for debugging -
are missing = 0
clisp: Provides detailed debugging information = 1
Corman: Returns messages like "Stack Frame Error", or will simply crash = 0
clisp: Improved FFI = 0
Corman: Powerful FFI, COM support etc. = 1
clisp: Free = 1
Corman: Purchase = 0
OK, lets tally these up.
clisp = 7
Corman = 2
"Cruise Director" <···········@gmail.com> writes:
> Brad Might wrote:
>
> I should probably refrain from wasting my time arguing with people who
> don't know what production realities are.
Two misspellings there:
"my" should be "your"
"arguing with people who don't know what production realities are"
should be "here"
HTH,
Zac
"Cruise Director" <···········@gmail.com> writes:
> Brad Might wrote:
> >
> > If you care that much about it, and are more interested in its
> > existence than decrying the lack of it, you could probably punch out a
> > first version of your universal OpenGL 2.0 bindings in less than a
> > week. At that point you might be able to convince some of the community
> > to give it some testing. In the amount of time you have spent
> > convincing us that it is a fatal flaw, you could have already completed
> > it and received glorious praise for your efforts.
>
> I get really tired of armchair generals who spout such gobbledygook.
> You clearly have done nothing to address such problems, to think this.
I've created OpenGL bindings (for UFFI) on OS X. They are not the
most stunning piece of Lisp work to be sure, but those APIs I've
actually tested did in fact work. I don't recall how much time I
actually spent on the job, but a week sounds about right.
I think I've actually published the bindings. IIRC, you need a Mac to
look at them as they are in a DMG file with the program that uses them
to draw a pyramid.
> Nor can you probably even formulate what the problems are. You are
> most likely a typical non-commercial computer guy who just talks out
> his ass about how little time it takes to get things done. I think the
> rule of thumb is to multiply such people's time estimates by 4x. A
> real expert, by 2x. Anyways, I continue to plod along with the
> realities of tools and APIs that are either not production quality or
> not really portable.
You continue to post complaints about the quality of tool chains here,
but you have posted no evidence that you have tried to make do with
what is actually available. Nor have you posted any evidence that you
have tried to improve the situation.
> I should probably refrain from wasting my time arguing with people who
> don't know what production realities are.
I have no idea what the production realities for games are. But I've
worked in the professional development arena and know exactly what the
production realities of software development are. I am beginning to
suspect that you don't.
> At least since someone made a plea for help, I've given an outline of
> the status quo. Lisp is very much proven in 3D graphics, much moreso
> over its history than any of the other HLLs. But no, as of today, it
> is not production quality. I think it's fair to say that Lisp had its
> 3D glory in the past, and that only big, unique codebases are carrying
> that legacy forwards today. Commodity production tools for 3D just
> aren't out there in open source land; people will have to either build
> them or buy them.
Well there's a revelation.
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
On 2005-11-10, Cruise Director <···········@gmail.com> wrote:
> I should probably refrain from wasting my time arguing with people who
> don't know what production realities are.
So how many games have you shipped?
(Along these lines, why does it seem like there have been a lot of
annoying "I want to use CL for games but can't {afford a commercial
compiler, deal with the open source solutions}" on cll lately?)
--
Julian Squires
Julian Squires
(Along these lines, why does it seem like there have been a lot of
annoying "I want to use CL for games but can't {afford a commercial
compiler, deal with the open source solutions}" on cll lately?)
Because there is a lot of wanna be Lispers and very few write-lisp-code
Lispers.
Most people just *love* Lisp like an sports club .
They would argue and advocate their pet to death but actually they'll
never go to any match,
join any fan club or buy some requisit with their beloved club.
Many people want to use Lisp but they don't wanna put any effort in
learning it beside
first two chapters of ACL.
How I know this ?I use to be one of them
regards
bobi
"Brad Might" <······@gmail.com> writes:
>
> If you care that much about it, and are more interested in its
> existence than decrying the lack of it, you could probably punch out a
> first version of your universal OpenGL 2.0 bindings in less than a
> week. At that point you might be able to convince some of the community
Maybe (just maybe; I haven't tried) less than five minutes with
Verrazano.
> to give it some testing. In the amount of time you have spent
> convincing us that it is a fatal flaw, you could have already completed
> it and received glorious praise for your efforts.
But where's the fun in that?
Our Cruise Director is a variation on Robert Maas, with a somewhat
bigger ego. They both excel in the 'Why don't you... Yes but...' game
described by Eric Berne.
Andras
Brad Might wrote:
> If you care that much about it, and are more interested in its
> existence than decrying the lack of it, you could probably punch out a
> first version of your universal OpenGL 2.0 bindings in less than a
> week.
Brandon does have a point though. If it is as easy as you say it is, I would
expect there to be at least one up-to-date set of OpenGL bindings.
I spent a month trying to write OCaml bindings just for the GLU tesselator,
found it very hard and came up short. The problems were down to strong
typing and safety. I believe those problems would also exist in Lisp
bindings (perhaps run-time type information makes things easier?).
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Brad Might wrote:
> > If you care that much about it, and are more interested in its
> > existence than decrying the lack of it, you could probably punch out a
> > first version of your universal OpenGL 2.0 bindings in less than a
> > week.
>
> Brandon does have a point though. If it is as easy as you say it is, I would
> expect there to be at least one up-to-date set of OpenGL bindings.
>
I suspect that the real reason is that there is not a lot of demand for
it. Those of us that need it took the time to do what we needed
ourselves (see above, me, Luke, David) and didn't sit around bitching
about it. If Brandon had really wanted OpenGL bindings for any platform
then he could easily (assuming he's capable of learning an ffi) have
done it.
He makes proclamations that there must be open source software
available to run what i want to run on every platform or else it's not
worth the time to apply myself.
At least he has finally found something (Chicken Scheme) that he might
be making some progress with.
Brandon's issues could be solved by making a decision, picking a
direction and doing it, instead of finding additional ways to
procrastinate.
Pascal Bourguignon wrote:
>
> AFAIK, GOAL was written in CL. The point is that you use CL to do
> meta-programming.
I would need to see this quoted in an article somewhere before I
believed it. I have followed the Naughty Dog story on a number of
occasions, and never once have I seen CL mentioned. The story is
always that Franz did custom work with Naughty Dog to produce GOAL.
I'm sure the Franz guys could answer authoritatively if they wish.
> >> and Lush which is designed with 3D graphics in mind.
> >> http://lush.sourceforge.net/
> >
> > Lush is a Lisp, but it is not Common Lisp. Just trying to be clear on
> > Common Lisp's capabilities and support, vs. all the Lisps that have
> > ever existed. Certainly, various Lisps have been used for 3D graphics
> > problems over and over again.
>
> And this is another thing I regret and don't understand: why do they
> still fork inferior lisps when they could improve Common Lisp?
Because IIRC, Lush got started when Common Lisp wasn't much solidified.
Seems perfectly reasonable to keep going with what works for them.
Good development systems are not theory, they're implementation. Tons
and tons of tedious implementation. Lush has gotten a whole lot of
work done for a particular set of tasks. If I were the Lush author,
what incentive would I have to get it all working in CL? Every CL is
different anyways; for a number of problems it's not all that 'common'.
Cheers,
Brandon Van Every
I won't spend more than 1 day configuring 1 thing.
"Cruise Director" <···········@gmail.com> writes:
> Pascal Bourguignon wrote:
>>
>> AFAIK, GOAL was written in CL. The point is that you use CL to do
>> meta-programming.
>
> I would need to see this quoted in an article somewhere before I
> believed it. I have followed the Naughty Dog story on a number of
> occasions, and never once have I seen CL mentioned. The story is
> always that Franz did custom work with Naughty Dog to produce GOAL.
> I'm sure the Franz guys could answer authoritatively if they wish.
Duanne Retig (of Franz) already has. See:
Message-ID: <··············@franz.com>
Short version: GOAL was a domain specific language written in Common
Lisp by developers at Naughty Dog.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On 2005-11-07 13:17:05 -0500, John Connors <·····@yagc.ndo.co.uk> said:
> Help. My supervisor thinks that there are fundamental problems with Lisp
> and 3d graphics: I have no idea why he could think that, but I seem to
> need counter - examples:
You might want to contact Professor Alexander Repenning who did the
OpenGL interface for commercial MCL. He seems to think that an
ephemeral GC is essential to avoid pauses. He can be reached at ralex
at cs dot colorado dot edu. His website is at w3 dot cs dot colorado
dot edu slash tilde ralex.
John Connors writes:
> c.l.l inhabitants,
>
> Help. My supervisor thinks that there are fundamental problems with Lisp
> and 3d graphics: I have no idea why he could think that, but I seem to
> need counter - examples: I know of cells-gtx & the clim which are
> fantastic gui's, but little of any good 3d engines: I know of sdl-opengl
> bindings, and the glx component of clx, and I strongly suspect this is
> yet another pernicious Lisp Myth, but these aren't actual applications I
> can point to.
>
> Does anyone have any suggestions? .
>
I've played with 3D and OpenGL [1]. I've translated directly C
examples code to Lisp. Here is what I saw :
Under GNU/Linux:
I got the same speed with CMUCL (71.5 FPS) and with the original C
code (71.5 FPS).
CLisp is ~12% slower (62.5 FPS) on this plateform.
Under Window:
CLisp run the maiden demo ~50% faster than the CMUCL / C code under
Windows (166.7 FPS)
So I think (for me) the greatest limitation is my graphic card under
GNU/Linux.
I've seen nothing wrong with the garbage collector as all objects are
allocated at startup as in the C code. But the examples are relatively
simples and doesn't require a lot of calculations other than in the
OpenGL library part.
[1] http://hocwp.free.fr/ah2cl/
--
Philippe Brochard <···········@SPAM_free.fr>
http://hocwp.free.fr
"John Connors" <·····@yagc.ndo.co.uk> wrote
>
> c.l.l inhabitants,
>
> Help. My supervisor thinks that there are fundamental problems with Lisp
> and 3d graphics: I have no idea why he could think that, but I seem to
> need counter - examples: I know of cells-gtx & the clim which are
> fantastic gui's, but little of any good 3d engines: I know of sdl-opengl
> bindings, and the glx component of clx, and I strongly suspect this is
> yet another pernicious Lisp Myth, but these aren't actual applications I
> can point to.
>
> Does anyone have any suggestions? .
A 100% Common Lisp industrial application with real time motion control and
data acquisition with OpenGL display:
http://www.fractalconcept.com/asp/j8h/sdataQ09YzecHQNLXDM==/T8hsdataQocY9wWG
Z0xi
Marc
Marc Battyani wrote:
> "John Connors" <·····@yagc.ndo.co.uk> wrote
>
>>c.l.l inhabitants,
>>
>>Help. My supervisor thinks that there are fundamental problems with Lisp
>>and 3d graphics: I have no idea why he could think that, but I seem to
>>need counter - examples: I know of cells-gtx & the clim which are
>>fantastic gui's, but little of any good 3d engines: I know of sdl-opengl
>>bindings, and the glx component of clx, and I strongly suspect this is
>>yet another pernicious Lisp Myth, but these aren't actual applications I
>>can point to.
>>
>>Does anyone have any suggestions? .
>
>
> A 100% Common Lisp industrial application with real time motion control and
> data acquisition with OpenGL display:
> http://www.fractalconcept.com/asp/j8h/sdataQ09YzecHQNLXDM==/T8hsdataQocY9wWG
> Z0xi
>
> Marc
>
>
Thanks, this is the kind of thing I was looking for! I already know
about GOAL, and that garbage collection in soft realtime systems is a
solved problem...
John Connors
John Connors wrote:
> - examples: I know of cells-gtx & the clim which are
> fantastic gui's, but little of any good 3d engines: I know of sdl-opengl
> bindings, and the glx component of clx,
I wrote Lisp bindings for Corman Lisp both SDL as well as a scene graph
manager called OpenRM (openrm.org).
And just this evening I managed to get OpenRM running within an SDL
window in Lispworks for Windows. I'll post the Lispworks FLI definitions
at http://balooga.com/lisp.php3 when I get a chance.
-Luke
Luke J Crook wrote:
> John Connors wrote:
> > - examples: I know of cells-gtx & the clim which are
> > fantastic gui's, but little of any good 3d engines: I know of sdl-opengl
> > bindings, and the glx component of clx,
>
> I wrote Lisp bindings for Corman Lisp both SDL as well as a scene graph
> manager called OpenRM (openrm.org).
>
> And just this evening I managed to get OpenRM running within an SDL
> window in Lispworks for Windows. I'll post the Lispworks FLI definitions
> at http://balooga.com/lisp.php3 when I get a chance.
Yeah, that's true, things are rosier on the sci-vis side of things. I
just didn't think OpenRM looked appropriate for game development.
Cheers,
Brandon Van Every
Cruise Director wrote:
> Luke J Crook wrote:
> just didn't think OpenRM looked appropriate for game development.
Maybe it is, maybe it isn't. I'm betting that it is perfectly suited to
game development.
- The DLL is small, like 260KB tiny.
- The library exports a very clean C API.
- Wes, the maintainer, is very much on the ball and knows scene graphs
inside and out.
- The OpenRM documentation is second to none. It costs ($5), and is 578
pages of pure reading goodness. The library is so well documented that
it almost brings tears to my eyes.
- OpenRM may not be OpenGL 2.0, but I'm willing to throw that troll
over the bridge when the need arises.
-Luke
Luke Crook wrote:
> Cruise Director wrote:
> > Luke J Crook wrote:
>
> > just didn't think OpenRM looked appropriate for game development.
>
> Maybe it is, maybe it isn't. I'm betting that it is perfectly suited to
> game development.
>
> - The DLL is small, like 260KB tiny.
> - The library exports a very clean C API.
Yeah, it's like the only decently licensed C engine out there.
Everything else is C++ and that's hard to talk to.
> - Wes, the maintainer, is very much on the ball and knows scene graphs
> inside and out.
> - The OpenRM documentation is second to none. It costs ($5), and is 578
> pages of pure reading goodness. The library is so well documented that
> it almost brings tears to my eyes.
> - OpenRM may not be OpenGL 2.0, but I'm willing to throw that troll
> over the bridge when the need arises.
I'm rather leery of 3D engine architectures that were designed a long
time ago and have no notion of shaders as industry currently practices
them. Sounds like one big major PITA when you finally decide that yes,
Matilda, you really do need shaders. Sci-vis guys think they don't
need shaders, that OpenGL 0.002 works just fine or whatever. Game
developers generally want the latest greatest, with fallbacks when the
HW doesn't support their favorite wonder feature. Unless you can point
me at games that have been done in OpenRM, I seriously doubt that
OpenRM contends with such issues. I'd expect it to be driven by the
needs of the sci-vis market, not the game market.
Another issue is that OpenRM is someone else's huge pile of code. It
is probably easier for me to write my own code, implement far less, and
concentrate on what I specifically need.
Another issue is if nobody's using OpenRM for games, then you don't get
peripheral labor for things like Maya plugins, audio integration, etc.
You end up doing everything yourself.
Cheers,
Brandon Van Every
I am writing 3d game code which uses opengl as the display library.
I am using Lispworks Common Lisp on Windows XP and have no problems at
all with
the speed.
John Connors wrote:
> c.l.l inhabitants,
>
> Help. My supervisor thinks that there are fundamental problems with Lisp
> and 3d graphics: I have no idea why he could think that, but I seem to
> need counter - examples: I know of cells-gtx & the clim which are
> fantastic gui's, but little of any good 3d engines: I know of sdl-opengl
> bindings, and the glx component of clx, and I strongly suspect this is
> yet another pernicious Lisp Myth, but these aren't actual applications I
> can point to.
>
> Does anyone have any suggestions? .
>
> John Connors.
> http://badbyteblues.blogspot.com