Re: Why Lisp supposedly "sucks for game development"

From: Matthew Danish (mrd+nospam_at_cmu.edu)
Date: 10/23/04 

Date: 23 Oct 2004 15:26:25 -0400

knos@free.fr (n++k) writes:
> This precludes making use of any interactive intepretive
> read-eval-loop at the beginning of the development, as any non
> optimized code you may add in the inner loop may completly kill the
> results. Or start to massively CONS. (see next)

No it doesn't, actually, since most interactive read-eval-print-loops
are just as fully optimized and compiled as code in files. I can
verify this from personal experience, having modified my CL-SDL
programs in mid-run and having them continue to run without problems.
(Using threads, too).

> o Jitter can not be tolerated
>
> The human eye and ear dislikes jitter. And it breaks the immersive
> quality games look for. Garbage collection must thus be somehow cut or
> reduce to the minimum. Stalling like that also completly kills the
> interpretation of user's inputs. This causes heavy game play problems.

Not too difficult, so long as you don't play fast and loose with
memory in the inner loop.

> o Cohabit with the C world
>
> A substantial part of a work will have been coded in C (third-party
> libraries notably, audio engines etc)
>
> The runtime must cohabit with this in a polite way, and must not
> assume it has all the cpu and memory. Notably through support of
> threads: no global lock around the runtime, enable C code to call lisp
> and lisp call the C code even in multiple threads. Leave enough memory
> for C allocations.

This, unfortunately, I only got working one way: Lisp -> C. It was
enough for my purposes. Kenny, who works in Allegro mostly, has FFI
going both ways.

> o Support for totally unboxed floating point in the FFI
>
> To avoid putting pressure on the GC, it is required to use unboxed
> floating-point in the inner loop.

CMUCL can do this. It can use unboxed values wherever it can prove
that they won't escape. Just exploit closures, and arrays which can
also be unboxed.

> o Adequate and maintenable FFI layer
>
> Coding and maintaining by hand a FFI layer, because the ffi requires
> declaration of all the used C types and functions is an overhead
> (notably when the APIs are changing, as libraries evolve) that is not
> all that acceptable in a small team.

Not sure why this has to be maintained by hand? Plenty of automated
tools nowadays. I happened to do CL-SDL by hand, but that is after I
received the automatically generated code for OpenGL FFI declarations
that Timo was working on; SDL was much smaller by comparison.

> o One usually doesn't have the budget to maintain a compiler for all
> the specific targets (ps2, gamecube, xbox)

Yes, my target was already established: Linux. I don't know about
consoles.

> o C/C++ Game developers are cheap

Don't you get what you pay for? =) 

-- 
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org