I want to write a game where you can hunt people, cut off their heads
and collect their brains with stunning 3D graphics.
Is this possible with LISP or is LISP only good for ASCII games ?
Lester T. Linpord wrote:
> I want to write a game where you can hunt people, cut off their heads
> and collect their brains with stunning 3D graphics.
That's nice. Keep it virtual.
>
> Is this possible with LISP or is LISP only good for ASCII games ?
It's possible.
--ag
--
Artie Gold -- Austin, Texas
"Yeah. It's an urban legend. But it's a *great* urban legend!"
In article <····························@posting.google.com>,
················@yahoo.co.in (Lester T. Linpord) wrote:
> I want to write a game where you can hunt people, cut off their heads
> and collect their brains with stunning 3D graphics.
>
> Is this possible with LISP or is LISP only good for ASCII games ?
I think there was a version of MazeWars for Lisp Machines in the early
80's. But maybe I'm confusing it with the original that ran on Xerox
Altos. It only used 3D line graphics, but this was over 20 years ago
when processing power was many orders of magnitude slower and more
expensive, and real-time full-color graphics was not feasible even on
supercomputers.
But anyway, there's nothing preventing Lisp from being used as the
implementation language for a modern video game.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
················@yahoo.co.in (Lester T. Linpord) writes:
> I want to write a game where you can hunt people, cut off their heads
> and collect their brains with stunning 3D graphics.
NaughtyDog used Lisp to write Crash Bandicoot, Jak & Baxter, and Jak
II (Sony Playstation). You can read more about it here:
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
And see some screenshots from Jak II here:
http://www.gamershell.com/hellzone_Playstation_2_Jak_2.shtml
So I would say it's possible...
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Petter Gustad <·············@gustad.com> writes:
> ················@yahoo.co.in (Lester T. Linpord) writes:
>
>> I want to write a game where you can hunt people, cut off their heads
>> and collect their brains with stunning 3D graphics.
>
> NaughtyDog used Lisp to write Crash Bandicoot, Jak & Baxter, and Jak
> II (Sony Playstation).
The same engine is also used for Insomnia's "Ratchet & Clank"
series, which is absolutely great.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
From: Karl A. Krueger
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <c00o8v$i6$1@baldur.whoi.edu>
Raymond Wiker <·············@fast.no> wrote:
> Petter Gustad <·············@gustad.com> writes:
>> ················@yahoo.co.in (Lester T. Linpord) writes:
>>
>>> I want to write a game where you can hunt people, cut off their heads
>>> and collect their brains with stunning 3D graphics.
>>
>> NaughtyDog used Lisp to write Crash Bandicoot, Jak & Baxter, and Jak
>> II (Sony Playstation).
>
> The same engine is also used for Insomnia's "Ratchet & Clank"
> series, which is absolutely great.
On the subject of violent games, though, wasn't Crack Dot Com's side-
scroller "Abuse" made with Lisp on the inside?
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
From: Christopher C. Stacy
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <ur7x7c254.fsf@news.dtpq.com>
>>>>> On Fri, 6 Feb 2004 19:00:49 +0000 (UTC), Karl A Krueger ("Karl") writes:
Karl> Raymond Wiker <·············@fast.no> wrote:
>> Petter Gustad <·············@gustad.com> writes:
>>> ················@yahoo.co.in (Lester T. Linpord) writes:
>>>
>>>> I want to write a game where you can hunt people, cut off their heads
>>>> and collect their brains with stunning 3D graphics.
>>>
>>> NaughtyDog used Lisp to write Crash Bandicoot, Jak & Baxter, and Jak
>>> II (Sony Playstation).
>>
>> The same engine is also used for Insomnia's "Ratchet & Clank"
>> series, which is absolutely great.
Karl> On the subject of violent games, though, wasn't Crack Dot Com's side-
Karl> scroller "Abuse" made with Lisp on the inside?
I thought we were trying stop the abuse around here?
Geez, I never get these memos. Maybe they're over
on DST's site; I'll go look there.
Raymond Wiker <·············@fast.no> wrote in message news:<··············@raw.grenland.fast.no>...
> The same engine is also used for Insomnia's "Ratchet & Clank"
> series, which is absolutely great.
Is this right? Did Insomnia buy it or the other way around? I'm
curious because we have one of the J&D games, and both R&C's (which
are, as you say, brilliant), and they're obviously similar, but I'd
assumed they were different engines as R&C is much nicer to play I
think.
In R&C2, Clank has a picture of J&D in his apartment, which I'd
assumed was just a little complement, but maybe there's more to it.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> Raymond Wiker <·············@fast.no> wrote in message news:<··············@raw.grenland.fast.no>...
>
>> The same engine is also used for Insomnia's "Ratchet & Clank"
>> series, which is absolutely great.
>
> Is this right? Did Insomnia buy it or the other way around? I'm
> curious because we have one of the J&D games, and both R&C's (which
> are, as you say, brilliant), and they're obviously similar, but I'd
> assumed they were different engines as R&C is much nicer to play I
> think.
It says so in the credits for Ratchet and Clank. It is also
: mentioned on a number of web sites, e.g,
http://www.gaming-age.com/cgi-bin/reviews/review.pl?sys=ps2&amp;amp;game=ratchetandclank
: Insomniac took a heavily tweaked version of Naughty Dog's impressive
: Jak and Daxter engine, and put together a thoroughly fun to play
: platformer that does pretty much everything right.
I finished Ratchet & Clank (the original) last week, and am
now "working" on the followup. I doubt I'll ever buy a PC game again
(unless there is a "Might & Magic X" :-)
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
> NaughtyDog used Lisp to write Crash Bandicoot, Jak & Baxter, and Jak
> II (Sony Playstation). You can read more about it here:
I don't really know how completely you can say that. The article you
linked to talks about creating tools to handle behaviors and object
control, and doesn't specifically mention using Lisp for the graphics
engine (which is what the OP is probably referring to). The reason I'm
wary of saying that Jak and Daxter used Lisp in the same way PC games
use C is because the PS2 architecture is such that you can't even get
good performance from it in C. Its a very specialized architecture
with one general-purpose MIPS processor and two asymetric vector
co-processors (one of which can operate in two modes), as well as a
seperate graphics co-processor. Its got a lot of computational power
available, but its really hard to tap. As a result, to get really good
performance out of it, most game designers resort to asm, not so much
for its speed, but because of the control it offers. So Lisp might
have been used for the bulk of the game logic, but the inner loops of
the graphics engine were probably in assembly.
On a general-purpose, PC-style architecture, a good Lisp compiler
could probably turn the inner loop of a graphics engine into something
competitive with the output of a C compiler. The Lisp code would
probably hit the instruction cache a little more heavily, but if you
worked with unboxed numbers, the data cache footprint should be about
the same. As long as you didn't blow the i-cache, performance should
be very competitive.
From: Duane Rettig
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <4bro8akma.fsf@franz.com>
·······@mindspring.com (Rayiner Hashem) writes:
> > NaughtyDog used Lisp to write Crash Bandicoot, Jak & Baxter, and Jak
> > II (Sony Playstation). You can read more about it here:
> I don't really know how completely you can say that. The article you
> linked to talks about creating tools to handle behaviors and object
> control, and doesn't specifically mention using Lisp for the graphics
> engine (which is what the OP is probably referring to). The reason I'm
> wary of saying that Jak and Daxter used Lisp in the same way PC games
> use C is because the PS2 architecture is such that you can't even get
> good performance from it in C. Its a very specialized architecture
> with one general-purpose MIPS processor and two asymetric vector
> co-processors (one of which can operate in two modes), as well as a
> seperate graphics co-processor. Its got a lot of computational power
> available, but its really hard to tap. As a result, to get really good
> performance out of it, most game designers resort to asm, not so much
> for its speed, but because of the control it offers. So Lisp might
> have been used for the bulk of the game logic, but the inner loops of
> the graphics engine were probably in assembly.
But that's precisely what they did. Why do so many Lispers have the
unshakable belief that the target of lisp compilations must be a lisp
machine, or even that it must run under all circumstances within a
lisp's environment? And why do you think they called this version
GOAL, or "Game Object _Assembler_ Language"? It is, in fact, precisely
what they did, only the high level compiling and assembling to bits was
all done on the development machine.
I worked with Andy Gavin under nondisclosure a couple of years ago,
to help him improve the performance of the combination of Allegro CL
and his GOAL compiler, and in March of last year I asked him if I
could answer some other questions on this newsgroup about his program.
He graciously consented, and the result is here:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=4bs0jaurq.fsf%40beta.franz.com
> On a general-purpose, PC-style architecture, a good Lisp compiler
> could probably turn the inner loop of a graphics engine into something
> competitive with the output of a C compiler. The Lisp code would
> probably hit the instruction cache a little more heavily,
Why do you say that? Lisp compilers nowadays tend to generate at least
as efficient code as C compilers, and in some cases it is more efficient,
depending on what higher order task is being compiled. And if the bulk of
a full lisp runtime is not needed for the task, why would such efficient
code blow the cache? On some of these machines, it is not a question of
staying within the cache sizes, it is a question of staying within the
_memory_ sizes. If the program doesn't stay within these sizes, the program
doesn't get less efficient; it simply doesn't _run_.
but if you
> worked with unboxed numbers, the data cache footprint should be about
> the same. As long as you didn't blow the i-cache, performance should
> be very competitive.
--
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
> But that's precisely what they did.
They wrote the game logic in Lisp and the graphics engine in MIPS ASM?
Maybe you didn't intend to say that they did *precisely* what I
thought they did, otherwise, why follow up?
> Why do so many Lispers have the
> unshakable belief that the target of lisp compilations must be a lisp
> machine, or even that it must run under all circumstances within a
> lisp's environment?
Its not so much a belief that the target of all lisp compilations must
be a Lisp machine, but perhaps a belief that if a particular
implementation does not follow the Lisp machine model, its not
*really* a Lisp.
> And why do you think they called this version
> GOAL, or "Game Object _Assembler_ Language"? It is, in fact, precisely
> what they did, only the high level compiling and assembling to bits was
> all done on the development machine.
My point was that the language would have had to deviate significantly
from Common Lisp to make effective use of the PS2 architecture. Unless
they implemented smarts in their compiler to automatically distribute
normal computations across the vector units, parts of GOAL would have
had to look like a macro-assembler, where programmers worked more or
less directly at the assembly level. I'm not doubting that Lisp is a
great tool for *writing* such a language, but it is streching the
definition (at least in my eyes) of "Lisp" to call such a language
"Lisp". Especially since Scheme supposedly isn't Lisp!
> Why do you say that? Lisp compilers nowadays tend to generate at least
> as efficient code as C compilers, and in some cases it is more efficient,
> depending on what higher order task is being compiled.
I guess it depends on the compiler, but overall, Lisp code tends to
use more indirection, which drives up code size, especially on non-x86
architectures, where it can take multiple instructions to compose a
pointer.
> And if the bulk of
> a full lisp runtime is not needed for the task, why would such efficient
> code blow the cache? On some of these machines, it is not a question of
> staying within the cache sizes, it is a question of staying within the
> _memory_ sizes.
Well, the PS2 has *tiny* caches. Its nearly impossible to keep data in
the cache, but since the PS2 has a lot of memory bandwidth its not a
big deal anyway. However, its definitely possible to avoid blowing the
instruction cache, and you get a nice performance boost if you do
that.
From: Duane Rettig
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <4bro8avel.fsf@franz.com>
·······@mindspring.com (Rayiner Hashem) writes:
> > But that's precisely what they did.
> They wrote the game logic in Lisp and the graphics engine in MIPS ASM?
Yes, they put the bits directly out for the MIPS processor.
> Maybe you didn't intend to say that they did *precisely* what I
> thought they did, otherwise, why follow up?
Why, indeed...
> > Why do so many Lispers have the
> > unshakable belief that the target of lisp compilations must be a lisp
> > machine, or even that it must run under all circumstances within a
> > lisp's environment?
> Its not so much a belief that the target of all lisp compilations must
> be a Lisp machine, but perhaps a belief that if a particular
> implementation does not follow the Lisp machine model, its not
> *really* a Lisp.
With such a belief you would then have to conclude there is no longer
any such thing as a Lisp, because most of the Lisps you can find
nowadays do not follow the Lisp machine model.
> > And why do you think they called this version
> > GOAL, or "Game Object _Assembler_ Language"? It is, in fact, precisely
> > what they did, only the high level compiling and assembling to bits was
> > all done on the development machine.
> My point was that the language would have had to deviate significantly
> from Common Lisp to make effective use of the PS2 architecture. Unless
> they implemented smarts in their compiler to automatically distribute
> normal computations across the vector units, parts of GOAL would have
> had to look like a macro-assembler, where programmers worked more or
> less directly at the assembly level. I'm not doubting that Lisp is a
> great tool for *writing* such a language, but it is streching the
> definition (at least in my eyes) of "Lisp" to call such a language
> "Lisp". Especially since Scheme supposedly isn't Lisp!
The greatest Power of Lisp, and especially Common Lisp, is that it
can be the best tool for writing other languages. In some senses
this makes CL self-deprecating. But so what? Why must the bits in
compiled code which have come from a Lisp compiler conform to any
protocol except for what the machine/runtime/environment want to
see? And what better language for creating such environments than
CL, which is the language-writer's language?
> > Why do you say that? Lisp compilers nowadays tend to generate at least
> > as efficient code as C compilers, and in some cases it is more efficient,
> > depending on what higher order task is being compiled.
> I guess it depends on the compiler, but overall, Lisp code tends to
> use more indirection, which drives up code size, especially on non-x86
> architectures, where it can take multiple instructions to compose a
> pointer.
Please show examples of this on a native-code-generating Common Lisp
implementation.
> > And if the bulk of
> > a full lisp runtime is not needed for the task, why would such efficient
> > code blow the cache? On some of these machines, it is not a question of
> > staying within the cache sizes, it is a question of staying within the
> > _memory_ sizes.
> Well, the PS2 has *tiny* caches. Its nearly impossible to keep data in
> the cache, but since the PS2 has a lot of memory bandwidth its not a
> big deal anyway. However, its definitely possible to avoid blowing the
> instruction cache, and you get a nice performance boost if you do
> that.
Well, then, obviously that's the kind of code which you want to generate
with your Lisp. You still haven't answered my question as to why Lisp-
generated code would blow the cache any more than C-generated code, or
even asm-generated code (which I presume would use some kind of macro
facility, as well).
--
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
·······@mindspring.com (Rayiner Hashem) writes:
> > But that's precisely what they did.
> They wrote the game logic in Lisp and the graphics engine in MIPS ASM?
> Maybe you didn't intend to say that they did *precisely* what I
> thought they did, otherwise, why follow up?
That I cannot coment on without some further reading. It sure lokos as
if most of the game9s) were written in GOAL:
[ cited from the Gama Sutra 'Post Mortem' referred to further down ]
"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. Before you dismiss us as
crazy, consider the many advantages of having a custom compiler."
> > Why do so many Lispers have the
> > unshakable belief that the target of lisp compilations must be a lisp
> > machine, or even that it must run under all circumstances within a
> > lisp's environment?
> Its not so much a belief that the target of all lisp compilations must
> be a Lisp machine, but perhaps a belief that if a particular
> implementation does not follow the Lisp machine model, its not
> *really* a Lisp.
There are some small snippets of GOAL code at
<URL:http://www.gamasutra.com/features/20020710/white_01.htm>
It looks liek a mix between CL and Scheme, though they seem to be
using the CL macro functionality. Also, GOAL is mentioned as both a
"What went right" and "What went wrong" (basically, it was essential
to the project's success but having only one or two that could poke
GOAL innards meant that whenever something was buggy inside, there was
slow-down).
//Ingvar
--
When it doesn't work, it's because you did something wrong.
Try to do it the right way, instead.
On 8649 day of my life Duane Rettig wrote:
> Lisp compilers nowadays tend to generate at least as efficient code
> as C compilers...
For example?
--
Ivan Boldyrev
Violets are red, Roses are blue. //
I'm schizophrenic, And so am I.
From: Duane Rettig
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <41xp28uhb.fsf@franz.com>
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8649 day of my life Duane Rettig wrote:
> > Lisp compilers nowadays tend to generate at least as efficient code
> > as C compilers...
>
> For example?
Interesting question. Not the question itself, but the way you
stripped my statement of the context from which it was stated,
and of course in that light it goes against the current wisdom
that the better Lisp compilers tend to generate code that is in
neighborhood within 20% of the speed of C (but on the slower side).
But that's not what the context was about. We're talking here not
about the code which Lisp generates for itself, which might be
slightly slower because of the demands (and advantages) of its
environment, but about the code which Lisp can generate for a
targeted environment. Note that C cannot just generate its own
code either; code it generates for itself usually assumes the
presence of libc (unless you are working with a special
cross-compiler geared toward the target already). The reason why
the conventional wisdom says that assembler is the way to go is
because there are usually no assumptions about the target
environment (though you do have to worry about what object
formats are supported by the target, if any, or whether you
have to create absolute rather than relocatable binaries).
I can't give you any examples in the Naughty Dog situation,
because of the Nondisclosure we are under. Instead, I'll
describe why the statement I made is true (within the correct
context):.
Lisp is good at treating code as data, and data as code, and its
compilers tend to cross that boundary as a matter of course. In
fact, (eval-when (compile) ...) wouldn't even be possible without
data-as-code an on-the-fly compilation. This is Lisp's strongest
suit, and Lisp does it better than most languages.
Now it is, of course, possible to treat code as data in C; in
fact, it is relatively trivial - all I have to do is to create an
array and fill it with bytes, and if the architecture requires it,
flush the data cache after writing those bytes. Depending on what
I put into that array, I might now have a vector of code which can
be jumped-to, or (if the bytes don't represent the machine I'm
targeting) I can ship that array off to the target machine and
start executing it by jumping to its beginning.
The problem is not generating the array, which is simply a matter
of filling in the "correct" bytes for the operations desired. The
real problem is in managing those bytes and figuring out how to figure
out what the correct bytes are to place into the target's code
vectors. Is can be done in C, and is done often, but when it is
done in Lisp the programmer has the power of being able to reason
about the data _as_ code built in.
I could go deeper into this, but either you're either getting it or
not, and I think for now it should suffice to say that when
generating code for target machines (as was the context of this
discussion) Lisp is much better suited than any other language,
because it has infrastructure and experience for treating data as
code.
--
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
From: Bulent Murtezaoglu
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <87vfme4k3c.fsf@cubx.internal>
>>>>> "DR" == Duane Rettig <·····@franz.com> writes:
[...]
DR> But that's not what the context was about. We're talking here
DR> not about the code which Lisp generates for itself, which
DR> might be slightly slower because of the demands (and
DR> advantages) of its environment, but about the code which Lisp
DR> can generate for a targeted environment. [..]
When I read it, I too thought you were talking about compiling plain
old lisp code but was thinking about tricks like runtime compilation
and such to get better speed than C (that's possible in certain cases
where there are optimization opportunities that you don't get to
find out until you see your data). That I was happy with. Now I
don't understand what you are saying!
[...]
DR> The problem is not generating the array, which is simply a
DR> matter of filling in the "correct" bytes for the operations
DR> desired. The real problem is in managing those bytes and
DR> figuring out how to figure out what the correct bytes are to
DR> place into the target's code vectors. Is can be done in C,
DR> and is done often, but when it is done in Lisp the programmer
DR> has the power of being able to reason about the data _as_ code
DR> built in.
OK. I think I understand this.
DR> I could go deeper into this, but either you're either getting
DR> it or not, and I think for now it should suffice to say that
DR> when generating code for target machines (as was the context
DR> of this discussion) Lisp is much better suited than any other
DR> language, because it has infrastructure and experience for
DR> treating data as code. [...]
Yes but the claim, as I now understand it, is that a compiler (written
in lisp) that compiles from the task-specific language to the target
machine code generates code that is 20% faster in some cases than the
same(???) compiler written in C. The above will make producing that
compiler very convenient for the lisp programmer, but where is the
extra performance coming from? Limited compiler programmer time?
If you feel like (and are able to) give more details that would be
lovely.
cheers,
BM
From: Duane Rettig
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <4bro5y3b9.fsf@franz.com>
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "DR" == Duane Rettig <·····@franz.com> writes:
> [...]
> DR> But that's not what the context was about. We're talking here
> DR> not about the code which Lisp generates for itself, which
> DR> might be slightly slower because of the demands (and
> DR> advantages) of its environment, but about the code which Lisp
> DR> can generate for a targeted environment. [..]
>
> When I read it, I too thought you were talking about compiling plain
> old lisp code but was thinking about tricks like runtime compilation
> and such to get better speed than C (that's possible in certain cases
> where there are optimization opportunities that you don't get to
> find out until you see your data). That I was happy with. Now I
> don't understand what you are saying!
:-)
> DR> I could go deeper into this, but either you're either getting
> DR> it or not, and I think for now it should suffice to say that
> DR> when generating code for target machines (as was the context
> DR> of this discussion) Lisp is much better suited than any other
> DR> language, because it has infrastructure and experience for
> DR> treating data as code. [...]
>
> Yes but the claim, as I now understand it, is that a compiler (written
> in lisp) that compiles from the task-specific language to the target
> machine code generates code that is 20% faster in some cases than the
> same(???) compiler written in C.
No, the only 20% figure I've given is the traditional wisdom which
places Lisp at about 20% slower than C in general. I've said nothing
about targeted cross-compilation being 20% faster than C-generated
equivalent, though I'm sure it might be possible, for limited periods
of time. I did assert that the Lisp would tend to generate code at
least as efficient as C, and possibly more efficient, depending on the
higher-level task being attempted. The problem with such assertions
in general, though, is that since the requirement for a compiled
target-environment's code boils down at the end to just a bunch of
bits, _any_ cross-compiler can generate those bits which comprise the
most efficient execution for that environment - even monkeys on
typewriters could generate that most-efficient-program, given enough
time. Lisp's advantage, though, is precisely that - time. Better code
for a targetted environment can be generated in a smaller amount of time
using a Lisp-based cross-compiler than with some other compiler.
As for why Lisp's runtime environment tends to be about 20% slower
than C's: it's the GC. The fact that a garbage-collector can move
objects once they've been allocated forces certain coding styles
which anticipates this movement. Many years ago, before Google records
it, Ken Anderson (of BBN) did some experimentation with gcc and Allegro
CL, working with a benchmark called "pfannkuch" (pancake, in German).
The inner loops he got down to 10 and 11 instructions respectively on
a Sparc, and the reason why Allegro needed two of the instructions in
the loop was to add an index to the array pointer each time, because
the array could move. We theorized that a potential optimization was
to allow an "atomically" macro act as sort of a declaration in the loop,
which would allow such power-reduction as turning the index into an
actual pointer, which then would allow us to generate a 9-instruction
loop - one instruction less than the gcc compilation! But we never
did that optimization; it wasn't worth getting a benchmark to run fast
but with no practical value in the real world.
> The above will make producing that
> compiler very convenient for the lisp programmer, but where is the
> extra performance coming from? Limited compiler programmer time?
> If you feel like (and are able to) give more details that would be
> lovely.
In a nutshell, it is the limited programmer time. When developing games,
you don't want your progrmmers to have to think about how to get
his character from here to there with the fewest cycles, you want them
to concentrate on game play at the higher level. Cross-compiling from
Lisp allows this with fewer tools, giving a lot of to-the-metal control
and yet high-level views at the same time.
--
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 <·····@franz.com> writes:
> [..] We theorized that a potential optimization was to allow an
> "atomically" macro act as sort of a declaration in the loop, which
> would allow such power-reduction as turning the index into an actual
> pointer, which then would allow us to generate a 9-instruction loop
> - one instruction less than the gcc compilation! But we never did
> that optimization; it wasn't worth getting a benchmark to run fast
> but with no practical value in the real world.
How about if such an atomically macro specified that in the event that
a GC is triggered during the atomic body's execution, some protocol is
invoked to the effect that the atomic body's dynamic environment is
thrown away? Then, none of the atomic body's dynamic environment need
be considered by the GC, and the code compiled lexically inside the
atomic body need not worry about anything moving. Throwing away the
dynamic environment obviously implies e.g. that the atomic body is
re-started, returns a special value, or sees a condition signalled
("exception situation"), or whatever.
The idea is, that if this atomic dynamic environment can be set up
reasonably cheaply (should be: only set a bit in the dynamic
environment), and the programmer understands the implications of using
this operator (i.e. don't cons very much, and be prepared to deal with
the bail-out situation).
I suspect this could have value in the real world, for applications
with tight inner loops. Also, it would be easy to have a no-op
implementation for run-times that doesn't implement atomically proper:
(defmacro atomically (options &body body)
(declare (ignore options))
(progn ,@body))
--
Frode Vatvedt Fjeld
From: Duane Rettig
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <47jytxz1w.fsf@franz.com>
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > [..] We theorized that a potential optimization was to allow an
> > "atomically" macro act as sort of a declaration in the loop, which
> > would allow such power-reduction as turning the index into an actual
> > pointer, which then would allow us to generate a 9-instruction loop
> > - one instruction less than the gcc compilation! But we never did
> > that optimization; it wasn't worth getting a benchmark to run fast
> > but with no practical value in the real world.
>
> How about if such an atomically macro specified that in the event that
> a GC is triggered during the atomic body's execution, some protocol is
> invoked to the effect that the atomic body's dynamic environment is
> thrown away? Then, none of the atomic body's dynamic environment need
> be considered by the GC, and the code compiled lexically inside the
> atomic body need not worry about anything moving. Throwing away the
> dynamic environment obviously implies e.g. that the atomic body is
> re-started, returns a special value, or sees a condition signalled
> ("exception situation"), or whatever.
Forcing a restart seems like a lot of extra work to do for a form
whose _intention_ is to run, as it were, "atomically". Our atomically
macro (actually, excl::atomically, for anyone wanting to experiment with
it, though please note that it is not exported, and thus not documented
or supported...) simply expands to its body, but if there is anything
non-atomic within the body (such as a call or an interrupt-check) then
compilation will fail with an error. It's as simple as that. There is
no extra code generated; the atomically macro makes use of the fact that
some short segments of code do not allow any interrupts or gc to occur
until they are done or until they cause an error (from which you can
indeed throw away the environment) and restart at a place in the stack
earlier than or less nested than the atomically form. Thus, those segments
of code within an atomically form are guaranteed to not allow interrupts,
and so the extra expense of binding a special as in a without-interrupts
form is circumvented but the guarantees are actually a little better.
> The idea is, that if this atomic dynamic environment can be set up
> reasonably cheaply (should be: only set a bit in the dynamic
> environment), and the programmer understands the implications of using
> this operator (i.e. don't cons very much, and be prepared to deal with
> the bail-out situation).
Our idea of cheap is no extra code generated!
> I suspect this could have value in the real world, for applications
> with tight inner loops. Also, it would be easy to have a no-op
> implementation for run-times that doesn't implement atomically proper:
>
> (defmacro atomically (options &body body)
> (declare (ignore options))
> (progn ,@body))
This looks similar to our version, though it compiles differently.
--
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 <·····@franz.com> writes:
> Forcing a restart seems like a lot of extra work to do for a form
> whose _intention_ is to run, as it were, "atomically".
"Atomically", after all, means (to me, anyway) "all or nothing", not
"all". And the "nothing" part must necessarily be user-specified. But
anyway, if this saves you 20% on the inner loop of your computation
99% of the time, it might be worth it even if those 1% take twice as
long as normal (i.e. 160%, which yields an average gain of
19.2%. .... I can also pull rabbits out of a hat.).
> Our atomically macro (actually, excl::atomically, for anyone wanting
> to experiment with it, though please note that it is not exported,
> and thus not documented or supported...) simply expands to its body,
> but if there is anything non-atomic within the body (such as a call
> or an interrupt-check) then compilation will fail with an error.
> It's as simple as that. There is no extra code generated; the
> atomically macro makes use of the fact that some short segments of
> code do not allow any interrupts or gc to occur until they are done
> or until they cause an error (from which you can indeed throw away
> the environment) and restart at a place in the stack earlier than or
> less nested than the atomically form. Thus, those segments of code
> within an atomically form are guaranteed to not allow interrupts,
> and so the extra expense of binding a special as in a
> without-interrupts form is circumvented but the guarantees are
> actually a little better.
So in Allegro a thread cannot be asynchronously interrupted, it is the
thread itself that must poll some status word and possibly transfer
control to an interrupt handler or GC? I guess this design makes true
concurrency difficult, btw.
If this is the case, doesn't it mean that excl::atomically knows
enough to compile its body without having to care about GC potentially
moving objects? Although, if I understand you correctly, this isn't
the point of excl::atomically, or even very interesting, since there
can't be any calls or anything else much fun inside its body.
>> The idea is, that if this atomic dynamic environment can be set up
>> reasonably cheaply (should be: only set a bit in the dynamic
>> environment), and the programmer understands the implications of using
>> this operator (i.e. don't cons very much, and be prepared to deal with
>> the bail-out situation).
>
> Our idea of cheap is no extra code generated!
The point is of course that the "extra" code (on the order of 1
instruction, I'd expect) in the body's preamble would allow the rest
of the body to be compiled with the assumption that no GC will
occur. And presumably, the rest of the body would be a loop with
sufficient iterations to make it worthwhile.
It's really an instance of make-the-common-case-fast: Assuming the
common case is that no GC occurs, allow the programmer to optimize for
that situation, accepting the penalty if the assumption should fail.
--
Frode Vatvedt Fjeld
From: Duane Rettig
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <4y8r9wcu3.fsf@franz.com>
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Forcing a restart seems like a lot of extra work to do for a form
> > whose _intention_ is to run, as it were, "atomically".
>
> "Atomically", after all, means (to me, anyway) "all or nothing", not
> "all". And the "nothing" part must necessarily be user-specified. But
> anyway, if this saves you 20% on the inner loop of your computation
> 99% of the time, it might be worth it even if those 1% take twice as
> long as normal (i.e. 160%, which yields an average gain of
> 19.2%. .... I can also pull rabbits out of a hat.).
Going back to original definitions, the name "atomically" was chosen
because of its reference to being not subdividable. In this case the
subdivision is with respect to gc. The fact that it also generates
faster code that would have been possible with normal anti-gc measures
is an added benefit, but not the primary goal.
> > Our atomically macro (actually, excl::atomically, for anyone wanting
> > to experiment with it, though please note that it is not exported,
> > and thus not documented or supported...) simply expands to its body,
> > but if there is anything non-atomic within the body (such as a call
> > or an interrupt-check) then compilation will fail with an error.
> > It's as simple as that. There is no extra code generated; the
> > atomically macro makes use of the fact that some short segments of
> > code do not allow any interrupts or gc to occur until they are done
> > or until they cause an error (from which you can indeed throw away
> > the environment) and restart at a place in the stack earlier than or
> > less nested than the atomically form. Thus, those segments of code
> > within an atomically form are guaranteed to not allow interrupts,
> > and so the extra expense of binding a special as in a
> > without-interrupts form is circumvented but the guarantees are
> > actually a little better.
>
> So in Allegro a thread cannot be asynchronously interrupted, it is the
> thread itself that must poll some status word and possibly transfer
> control to an interrupt handler or GC? I guess this design makes true
> concurrency difficult, btw.
Tedious, but not difficult. If the compiler can annotate the instructions
around an atomically form and the gc can allow that thread to run to a point
where it is not atomic before the collector performs critical data movement,
then the only problem is in determining when there is an infinite loop within
the form, and how to break out of that loop gracefully. No, the real difficulty
in concurrency is not dealing with code snippets which have been identified
as atomic; the real difficulty is in identifying code snippets which _should_
have been atomic but which aren't.
> If this is the case, doesn't it mean that excl::atomically knows
> enough to compile its body without having to care about GC potentially
> moving objects? Although, if I understand you correctly, this isn't
> the point of excl::atomically, or even very interesting, since there
> can't be any calls or anything else much fun inside its body.
Actually, the atomically form knows nothing; it is the compiler which
can be _made_ to know. Otherwise, I agree that it isn't the point of
excl::atomically, though it might indeed be interesting if real situations
can be demonstrated that are not trivial benchmarks. I suspect that in
array calculations and manipulations some of these situations do exist.
> >> The idea is, that if this atomic dynamic environment can be set up
> >> reasonably cheaply (should be: only set a bit in the dynamic
> >> environment), and the programmer understands the implications of using
> >> this operator (i.e. don't cons very much, and be prepared to deal with
> >> the bail-out situation).
> >
> > Our idea of cheap is no extra code generated!
>
> The point is of course that the "extra" code (on the order of 1
> instruction, I'd expect) in the body's preamble would allow the rest
> of the body to be compiled with the assumption that no GC will
> occur. And presumably, the rest of the body would be a loop with
> sufficient iterations to make it worthwhile.
I think that you're confusing a "guarantee" with a "control". Setting
a bit, or executing an instruction, or some other control mechanism
(such as is the case with without-interrupts, which binds a special),
causes the lisp environment to hold off in its potential gc or interrupt
action. But the atomically macro is not a control - it is a guarantee.
It does nothing different in the code it generates, but if the compiler
is successful in compiling the contents of the form, then the form is
guaranteed to be atomic. Here is another way to look at it; there are
many atomic code sequences in Allegro CL; many randomly executed
instructions are such that a gc will never take place as a result of
or immediately after its execution. However, one doesn't necessarily
know that a certain segment of code is atomic unless that code has
been successfully compiled with the atomically macro wrapped around it.
In other words, there are many more atomic code sequences than there
are (excl::atomically ...) forms, but only these forms are guaranteed
to be atomic.
> It's really an instance of make-the-common-case-fast: Assuming the
> common case is that no GC occurs, allow the programmer to optimize for
> that situation, accepting the penalty if the assumption should fail.
Optimizing is a different goal than atomicity. If there is an uncommon
case, with .0001% chance that it will be seen, and given a random
execution distribution (which is probably unrealistic, though) one would
only have to run the test 10000 times to approach 100% the probability of
hitting this uncommon case. Atomicity is not a question of common-case
optmization, though optimization can certainly come out of atomicity.
Instead, it's a matter of guarantees.
--
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
In article <·············@franz.com>, Duane Rettig <·····@franz.com> wrote:
> I think that you're confusing a "guarantee" with a "control". Setting
> a bit, or executing an instruction, or some other control mechanism
> (such as is the case with without-interrupts, which binds a special),
> causes the lisp environment to hold off in its potential gc or interrupt
> action. But the atomically macro is not a control - it is a guarantee.
> It does nothing different in the code it generates, but if the compiler
> is successful in compiling the contents of the form, then the form is
> guaranteed to be atomic. Here is another way to look at it; there are
> many atomic code sequences in Allegro CL; many randomly executed
> instructions are such that a gc will never take place as a result of
> or immediately after its execution. However, one doesn't necessarily
> know that a certain segment of code is atomic unless that code has
> been successfully compiled with the atomically macro wrapped around it.
> In other words, there are many more atomic code sequences than there
> are (excl::atomically ...) forms, but only these forms are guaranteed
> to be atomic.
I see how this works in the single-threaded case, but how does this work
in the case of having multiple OS-scheduled threads going on? Or was I
mistaken in thinking that Allegro CL supported OS-level threads on some
architectures?
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
From: Duane Rettig
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <4n07pw839.fsf@franz.com>
Brian Downing <·············@lavos.net> writes:
> In article <·············@franz.com>, Duane Rettig <·····@franz.com> wrote:
> > I think that you're confusing a "guarantee" with a "control". Setting
> > a bit, or executing an instruction, or some other control mechanism
> > (such as is the case with without-interrupts, which binds a special),
> > causes the lisp environment to hold off in its potential gc or interrupt
> > action. But the atomically macro is not a control - it is a guarantee.
> > It does nothing different in the code it generates, but if the compiler
> > is successful in compiling the contents of the form, then the form is
> > guaranteed to be atomic. Here is another way to look at it; there are
> > many atomic code sequences in Allegro CL; many randomly executed
> > instructions are such that a gc will never take place as a result of
> > or immediately after its execution. However, one doesn't necessarily
> > know that a certain segment of code is atomic unless that code has
> > been successfully compiled with the atomically macro wrapped around it.
> > In other words, there are many more atomic code sequences than there
> > are (excl::atomically ...) forms, but only these forms are guaranteed
> > to be atomic.
>
> I see how this works in the single-threaded case, but how does this work
> in the case of having multiple OS-scheduled threads going on?
It appears as though you think that excl::atomically is a locking
mechanism. Is that the case? Otherwise, please explain the reason
for your question. Perhaps if you explain how you see it working in
the single-threaded case, we can get down to the assumptions that
you've made that don't allow it to work for you in the
multiple-threaded case.
> Or was I
> mistaken in thinking that Allegro CL supported OS-level threads on some
> architectures?
You were not mistaken, but what does that have to do with atomically?
--
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
In article <·············@franz.com>, Duane Rettig <·····@franz.com> wrote:
> It appears as though you think that excl::atomically is a locking
> mechanism. Is that the case? Otherwise, please explain the reason
> for your question. Perhaps if you explain how you see it working in
> the single-threaded case, we can get down to the assumptions that
> you've made that don't allow it to work for you in the
> multiple-threaded case.
I think I misunderstood what your description of excl::atomically
entails, since the discussion came about by talking about assumptions
that data will not be moved by the GC. I'll go back and read more
carefully. :)
[Disclaimer: I've only used Allegro CL as the trial version, my
question was only out of curiosity, as CL implementation issues interest
me.]
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Duane Rettig <·····@franz.com> writes:
> [..] But the atomically macro is not a control - it is a
> guarantee. [..]
I started in this thread by describing a hypothetical, unnamed control
opertator. Then you mentioned excl::atomically, after which I have
probably been a bit unclear about which of the two I've been referring
to--not in my mind but in my writing.
I'm mostly interested in the hypothetical operator that I initially
described, and any insight you and others might have regarding this
idea. This would indeed be a control operator, the semantics of which
would enable the compiler to emit more efficient code for its body
forms, as I described previously.
> [..] Atomicity is not a question of common-case optmization, though
> optimization can certainly come out of atomicity. Instead, it's a
> matter of guarantees.
Certainly. I believe I understand and agree with everything you
write, except for the communication failure mentioned above.
--
Frode Vatvedt Fjeld
From: Duane Rettig
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <4smhhw8ge.fsf@franz.com>
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > [..] But the atomically macro is not a control - it is a
> > guarantee. [..]
>
> I started in this thread by describing a hypothetical, unnamed control
> opertator. Then you mentioned excl::atomically, after which I have
> probably been a bit unclear about which of the two I've been referring
> to--not in my mind but in my writing.
Huh? I looked on Google and in my gnus history, and the first I saw
of your postings was _after_ I first mentioned an atomically macro.
At the very least it was never unnamed. Perhaps you were _thinking_
about such an unnamed macro beforehand?
> I'm mostly interested in the hypothetical operator that I initially
> described, and any insight you and others might have regarding this
> idea. This would indeed be a control operator, the semantics of which
> would enable the compiler to emit more efficient code for its body
> forms, as I described previously.
I understand this, but such a control macro would very likely not
be called "atomically"; it would likely have another name.
> > [..] Atomicity is not a question of common-case optmization, though
> > optimization can certainly come out of atomicity. Instead, it's a
> > matter of guarantees.
>
> Certainly. I believe I understand and agree with everything you
> write, except for the communication failure mentioned above.
OK.
--
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
·······@mindspring.com (Rayiner Hashem) writes:
> > NaughtyDog used Lisp to write Crash Bandicoot, Jak & Baxter, and Jak
> > II (Sony Playstation). You can read more about it here:
> I don't really know how completely you can say that. The article you
> linked to talks about creating tools to handle behaviors and object
> control, and doesn't specifically mention using Lisp for the graphics
> engine (which is what the OP is probably referring to). The reason I'm
> wary of saying that Jak and Daxter used Lisp in the same way PC games
> use C is because the PS2 architecture is such that you can't even get
> good performance from it in C. Its a very specialized architecture
> with one general-purpose MIPS processor and two asymetric vector
> co-processors (one of which can operate in two modes), as well as a
> seperate graphics co-processor. Its got a lot of computational power
> available, but its really hard to tap. As a result, to get really good
> performance out of it, most game designers resort to asm, not so much
> for its speed, but because of the control it offers. So Lisp might
> have been used for the bulk of the game logic, but the inner loops of
> the graphics engine were probably in assembly.
>
> On a general-purpose, PC-style architecture, a good Lisp compiler
> could probably turn the inner loop of a graphics engine into something
> competitive with the output of a C compiler. The Lisp code would
> probably hit the instruction cache a little more heavily, but if you
> worked with unboxed numbers, the data cache footprint should be about
> the same. As long as you didn't blow the i-cache, performance should
> be very competitive.
The programmable language paradigm of Lisp can be extended downward to
the metal as it can be upward to the problem space.
Just write an assembler for the target machine, and implement a custom
language over it.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
On 2004-02-06 05:07:12, Lester T. Linpord wrote:
> Is this possible with LISP or is LISP only good for ASCII games ?
Yeah. Lisp was involved in the CGI of the Disney movie TRON.
And as an example for current games:
http://lemonodor.com/archives/000610.html
> I want to write a game where you can hunt people, cut off their heads
> and collect their brains with stunning 3D graphics.
You could do that...
...But you could do that in C++ as well...If you only allow the player
to collect brains, you're clearly guilty of "Thinking in C"
...in Lisp, however, you can do even MORE- Since it is a
dynamically-typed language, you could collect not only brains, but
hearts, lungs, etc, etc.
In C++, you would be forced to use ugly casts to create the necessary
heterogeneous container class to accomplish this.
(I think the original poster meant this as a parody of some of the
posts that have been appearing lately- At least I hope this is the
case :)
·····················@yahoo.com (Conrad Barski) writes:
> > I want to write a game where you can hunt people, cut off their heads
> > and collect their brains with stunning 3D graphics.
>
> You could do that...
>
> ...But you could do that in C++ as well...If you only allow the player
> to collect brains, you're clearly guilty of "Thinking in C"
>
> ...in Lisp, however, you can do even MORE- Since it is a
> dynamically-typed language, you could collect not only brains, but
> hearts, lungs, etc, etc.
Don't forget garbage.
Gregm
From: Christopher C. Stacy
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <uvfmjahgm.fsf@news.dtpq.com>
>>>>> On 06 Feb 2004 18:52:37 -0500, Greg Menke ("Greg") writes:
Greg> ·····················@yahoo.com (Conrad Barski) writes:
>> > I want to write a game where you can hunt people, cut off their heads
>> > and collect their brains with stunning 3D graphics.
>>
>> You could do that...
>>
>> ...But you could do that in C++ as well...If you only allow the player
>> to collect brains, you're clearly guilty of "Thinking in C"
>>
>> ...in Lisp, however, you can do even MORE- Since it is a
>> dynamically-typed language, you could collect not only brains, but
>> hearts, lungs, etc, etc.
I thought the popular violent video games these days involved cars?
Lisp has CARs built-in. You're all set.
From: Joe Marshall
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <vfmj4tcv.fsf@comcast.net>
·····················@yahoo.com (Conrad Barski) writes:
>> I want to write a game where you can hunt people, cut off their heads
>> and collect their brains with stunning 3D graphics.
>
> You could do that...
>
> In C++, you would be forced to use ugly casts to create the necessary
> heterogeneous container class to accomplish this.
Or you could subclass organs and use templates!
Imagine the carnage.
--
~jrm
From: Karl A. Krueger
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <c03s9o$2f7$1@baldur.whoi.edu>
Joe Marshall <·············@comcast.net> wrote:
> ·····················@yahoo.com (Conrad Barski) writes:
>>> I want to write a game where you can hunt people, cut off their heads
>>> and collect their brains with stunning 3D graphics.
>>
>> You could do that...
>>
>> In C++, you would be forced to use ugly casts to create the necessary
>> heterogeneous container class to accomplish this.
>
> Or you could subclass organs and use templates!
>
> Imagine the carnage.
I've got a WITH-OPEN-WOUND macro lying around somewhere ... ew, I should
clean that up.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
From: Joe Marshall
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <u1222ysk.fsf@comcast.net>
"Karl A. Krueger" <········@example.edu> writes:
>
> I've got a WITH-OPEN-WOUND macro lying around somewhere ... ew, I should
> clean that up.
Once again, the ability to patch a running system comes in handy.
May I suggest using a fluid binding?
--
~jrm
"Karl A. Krueger" <········@example.edu> writes:
> I've got a WITH-OPEN-WOUND macro lying around somewhere ... ew, I should
> clean that up.
If you have a roll of good bandage you could UNWIND it to PROTECT the
wound.
-dan
--
"please make sure that the person is your friend before you confirm"
"Karl A. Krueger" <········@example.edu> writes:
> Joe Marshall <·············@comcast.net> wrote:
> > ·····················@yahoo.com (Conrad Barski) writes:
> >>> I want to write a game where you can hunt people, cut off their heads
> >>> and collect their brains with stunning 3D graphics.
> >>
> >> You could do that...
> >>
> >> In C++, you would be forced to use ugly casts to create the necessary
> >> heterogeneous container class to accomplish this.
> >
> > Or you could subclass organs and use templates!
> >
> > Imagine the carnage.
>
> I've got a WITH-OPEN-WOUND macro lying around somewhere ... ew, I should
> clean that up.
I always thought the semantics of WITH-OPEN-WOUND were questionable.
I mean, if you have a condition, it may not make sense to close the
wound, and it *certainly* wouldn't make sense to close the wound
because of an error!
Yes, having too many wounds open at the same time could indeed kill
the process, but in the above case the cure seems worse than the
disease.
--
Fred Gilham ······@csl.sri.com
Thou shalt not convince stupid people to try cordless bungee jumping....
Thou shalt not substitute Semtex when all the Playdough's gone....
Thou shalt not bob for hand grenades....
From: Joe Marshall
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <hdy0jkob.fsf@ccs.neu.edu>
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> I always thought the semantics of WITH-OPEN-WOUND were questionable.
> I mean, if you have a condition, it may not make sense to close the
> wound, and it *certainly* wouldn't make sense to close the wound
> because of an error!
That's true, many people think they can handle it, but when the time
comes they find themselves in a bind.
> --
> Fred Gilham ······@csl.sri.com
> Thou shalt not convince stupid people to try cordless bungee jumping....
Whyever not?
--
~jrm
Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
>
> Or you could subclass organs and use templates!
>
Well, without runtime type checking, you'd probably end up collecting
Hammond organs, or even church organs when you meant to get lungs,
spleens, etc. Your code would end up with some unexpected stops.
--tim
From: Joe Marshall
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <4qu0jd3r.fsf@ccs.neu.edu>
··········@tfeb.org (Tim Bradshaw) writes:
> Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
>
>>
>> Or you could subclass organs and use templates!
>>
>
> Well, without runtime type checking, you'd probably end up collecting
> Hammond organs, or even church organs when you meant to get lungs,
> spleens, etc. Your code would end up with some unexpected stops.
True, but I would of course use the appropriate &key argument.
(Backpedaling furiously here....)
Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
>
> True, but I would of course use the appropriate &key argument.
You'd have to do that manually though. Or possably in C. Avoid C#
though: too many accidentals.
> (Backpedaling furiously here....)
Ah, this is going to be a *cycling* video game. Watch out for the
CARs, and make sure your cons-chain doesn't become unlinked if you
backpedal too fast.
I'll get my coat.
From: Joe Marshall
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <1xp3898u.fsf@comcast.net>
··········@tfeb.org (Tim Bradshaw) writes:
> Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
>
>>
>> True, but I would of course use the appropriate &key argument.
>
>
> You'd have to do that manually though. Or possably in C. Avoid C#
> though: too many accidentals.
I cannot believe you would mention such things. Are you trying to
make me lose my even temper?
I'd prefer to get Bach to Basic.
--
~jrm
From: Karl A. Krueger
Subject: Re: Can I write brutal 3D shooters in lisp?
Date:
Message-ID: <c08mov$k8r$1@baldur.whoi.edu>
Tim Bradshaw <··········@tfeb.org> wrote:
> Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
>>
>> Or you could subclass organs and use templates!
>
> Well, without runtime type checking, you'd probably end up collecting
> Hammond organs, or even church organs when you meant to get lungs,
> spleens, etc. Your code would end up with some unexpected stops.
Well hey, if it works for Knuth ....
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
················@yahoo.co.in (Lester T. Linpord) writes:
> I want to write a game where you can hunt people, cut off their heads
> and collect their brains with stunning 3D graphics.
>
> Is this possible with LISP or is LISP only good for ASCII games ?
I'm trying to judge if this is a good troll or not. It made me
laugh. Does that count?
Since OpenGL bindings are available for CMUCL and presumably other
Lisps, I would expect the answer to the question to be yes.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> ················@yahoo.co.in (Lester T. Linpord) writes:
>
>> I want to write a game where you can hunt people, cut off their heads
>> and collect their brains with stunning 3D graphics.
>>
>> Is this possible with LISP or is LISP only good for ASCII games ?
>
> Since OpenGL bindings are available for CMUCL and presumably other
> Lisps, I would expect the answer to the question to be yes.
Patient: OK, just tell me one thing, Doctor. will I be able to play
the violin if I have the operation?
Doctor: yes, sure, why not?
Patient: that's great, Doctor! I've always dreamed about being able
to play the violin!
(there are probably better-told versions of this joke around),
--m
--
A computer, to print out a fact,
Will divide, multiply, and subtract.
But this output can be
No more than debris,
If the input was short of exact.
-- Gigo
David Steuber:
| Lester T. Linpord:
| > I want to write a game where you can hunt people, cut off their heads
| > and collect their brains with stunning 3D graphics.
| >
| > Is this possible with LISP or is LISP only good for ASCII games ?
|
| I'm trying to judge if this is a good troll or not.
Google knows all:
http://groups.google.com/groups?q=author:Lester_t_linpord%40yahoo.co.in
http://groups.google.com/groups?threadm=fd16a342.0312172135.435ab329%40posti
ng.google.com
http://groups.google.nl/groups?selm=c82725e2.0310161252.4a4287c9%40posting.g
oogle.com
The Giga Troll stikes again. He seems to like comp.lang.lisp; Let us hope
this is not going to become a habit of his.
--
Sebastian Stern
"Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all else
follows
················@yahoo.co.in (Lester T. Linpord) writes:
> I want to write a game where you can hunt people, cut off their heads
> and collect their brains with stunning 3D graphics.
>
> Is this possible with LISP or is LISP only good for ASCII games ?
No, Lisp compilers all come with a special device that
prevents them being used for anything other than artificial
intelligence and delivers huge electric shocks whenever
you use any data structure other than lists. But you
could use Lisp to implement the brains. Hope this helps.
--
Gareth McCaughan
.sig under construc
On Thu, 05 Feb 2004 20:07:12 -0800, Lester T. Linpord wrote:
> I want to write a game where you can hunt people, cut off their heads
> and collect their brains with stunning 3D graphics.
>
> Is this possible with LISP or is LISP only good for ASCII games ?
Yes. Go for it!
You will benefit from garbage collector that will collect corpses for you.
But beware of macros. They could make killing more abstract and
transparent. Most players won't be satisfied with that.
Jakub Travnik
·············@jabber.com
ICQ: 66770334