[Jörg Höhle]

Hi,

Here are pathes to make cl-sdl work with CLISP (tested
only on Linux, not win32).
They require my UFFI wrapper macros, from
http://sourceforge.net/tracker/index.php?func=detail&aid=1028683&group_id=1355&atid=301355

Most patches deal with badly quoted FFI types in the
demo files. The types were not consistently quoted (or
more precisely, *not* quoted). That's nothing to do
with CLISP proper.
Some patches deal with CLISP's peculiar
merge-namestring and probe-file behaviour.

I also made changed examples/data.lisp: it must move
away from
pathname-directory, which solely works on UNIX, and use
a full
pathname object (including device), for MS-Windows.

Other changes affect nehe/vertex-array where uffi:uchar
was used instead of uffi:ubyte.
Other changes affect some "0 is not a float" type
propagation errors. I correct some with adequate
coercions, but in the end maybe I got tired and just
set this in CLISP:
(setq custom:*floating-point-rational-contagion-ansi* t)

To use my UFFI wrappers, you must load first load my
ffi-patches-cvs.lisp, then my uffi.asd, then have it
load my uffi.lisp. Then eval (ext:cd in cl-sdl/):
(push (cons "sdlstub" "c/sdlstub.so")
uffi::*module-translations*)
(push (cons "sdl" "/usr/lib/libSDL.so")
uffi::*module-translations*)
(push (cons "opengl" "/usr/lib/libGL.so")
uffi::*module-translations*)
(push (cons "glu" "/usr/lib/libGLU.so")
uffi::*module-translations*)
or whereever your libraries are
before loading the system cl-ffi!

Surprisingly, the demos run as fast with cmucl as with
clisp. Obviously the bottleneck is not bytecode vs.
native code, but the speed of the graphics processor.

Here's a case were clisp was even slightly faster (no
idea why), yet generally the numbers are the same:
o Performance (sdl-example1:start)
speed clisp 2.35
Rectangles per second: 492.5
Rectangles per second: 752.5
Rectangles per second: 3201.5
Rectangles per second: 7756.875
Rectangles per second: 6594.5
Rectangles per second: 6444.0
Rectangles per second: 7799.7856
Rectangles per second: 8703.1875
Rectangles per second: 7977.5557
Rectangles per second: 7379.35
Rectangles per second: 7263.1816
Rectangles per second: 6823.875
o speed cmucl19c (surprisingly slower!?!)
Rectangles per second: 557.0
Rectangles per second: 945.5
Rectangles per second: 6664.8335
Rectangles per second: 7711.0
Rectangles per second: 6564.2
Rectangles per second: 5810.5
Rectangles per second: 5269.7856
Rectangles per second: 5487.5
Rectangles per second: 5103.5
Rectangles per second: 5347.1
Rectangles per second: 5045.3184

Regards,
Jörg Höhle.

diff to fix UFFI types and support for CLISP

Logged In: YES
user_id=377168

Oh, I forgot to add that
1. the patches are independent on my alternate UFFI
implementation. I.e. they should work with UFFI + CLISP the
day UFFI natively supports CLISP. And they work with cmucl.

2. because of CLISP bug
http://sourceforge.net/tracker/index.php?func=detail&aid=1211847&group_id=1355&atid=101355
you need to do
(load "sdl/sdl.lisp")
(load "sdl/sdl-ext.lisp")
after loading the system.
Actually
(load "sdl/sdl.lisp" :compiling t)
(load "sdl/sdl-ext.lisp" :compiling t)
should work as well, but not the .fas files.
The problem is one of object identity.

Regards,
Jörg Höhle.

Logged In: YES
user_id=377168

Actually, it's not the UFFI quoting that's wrong in some
examples (bad subject line of mine). The quoting is
simply contrary to the requirements for SGUM laid down in
the STYLE file: "All FFI wrapper macros should accept only
unevaluated types and slot names."

What happens is that the UFFI backend, after the SGUM->UFFI
transformation, will complain or not about the extra
quoting. Still, it's a bug.
There are currently three UFFI backends: UFFI,
CFFI-UFFI-compat and my own, for CLISP