Lisp HUG Maillist Archive

ODE/SDL/OpenRM FLI bindings

I've gone and made Lispworks FLI bindings to SDL, ODE (physics engine) and 
OpenRM (OpenGL scene graph manager).

As I don't have the professional version of Lispworks I have no idea just how 
large the resultant executable will be when including well over a megabyte of 
FLI bindings.

If someone has some time to spare, please download the archive from the location 
below and let me know (1) the executable size after a normal compile, and (2) 
the executable size after shaking the tree.

http://www.balooga.com/sdl_lispworks_v0.0.0.0.0.1.tar.gz

The archive includes a couple of examples as well as all the necessary DLL's for 
each of these packages. The description in each example explains how to run it. 
It's pretty straightforward I think.

Thanks,
-Luke


Re: ODE/SDL/OpenRM FLI bindings

On Wed, 28 Dec 2005 18:42:32 +0000 (UTC), Luke Crook <luke@balooga.com> wrote:

> If someone has some time to spare, please download the archive from
> the location below and let me know (1) the executable size after a
> normal compile, and (2) the executable size after shaking the tree.

I've played with this for a couple of minutes with the following
results:

1. By just loading your code as described (after changing one or two
   pathnames) I could run the examples.

2. Everything seemed to be quite slow and stopped moving as soon as I
   moved the mouse over the window.  This might be due to the code
   being interpreted (see below) or because my laptop's graphics card
   doesn't have proper OpenGL support - dunno.

3. Then I hacked a simple delivery script to deliver the
   "ode-test-gravity" example at level 0.  That worked (as above) and
   resulted in an EXE about 22MB big.

4. Now I tried to increase the delivery level and only then found out
   that most of your code was running interpreted.  (I had thought
   that your load scripts would take care of that.)  I started
   compiling and came across a couple of problems and warnings.[1]

5. I modified enough of the code to compile everything (albeit with
   some warnings) but now the resulting EXE didn't work anymore,
   neither at level 0 nor, of course, at higher levels.

6. FWIW, the (non-functioning) EXE at level 5 was slightly smaller
   than 3.5MB.

I'm willing to try my luck again but to spare me some time it'd be
nice if your code compiled cleanly and worked even in a compiled
state.

Cheers,
Edi.


[1] You should at least add

      (setf *handle-warn-on-redefinition* nil)

    somewhere because you're defining FLI bindings visible from the
    keyword package.  But there's more.


Re: ODE/SDL/OpenRM FLI bindings

On Wed, 28 Dec 2005 22:56:58 +0000 (UTC), Luke Crook <luke@balooga.com> wrote:

> I have tried these examples on a couple machines and the frame rate
> seems to be at least 60fps. Unless you are running Winnt, 2000 or XP
> (or have updated the drivers for your graphics chipset) then you
> probably do not have OpenGL drivers on your laptop. How much RAM do
> you have? Perhaps Lispworks is continually garbage collecting?

The laptop has 1.5GB RAM - I hope that's enough for OpenGL... :)

OS is WinXP pro SP2, the device manager says my graphics card is
called "ATI Mobility Fire GL T2".  How can I find out if I have OpenGL
drivers installed?

> Eek.

A size of 20GB or more isn't unusual for delivery level 0.  AFAIU
there's virtually no tree-shaking or whatever done at this level.  See
here

  <http://www.lispworks.com/documentation/lw445/DV/html/deluser.htm>

for all the gory details.

> I'm coming from a Corman Lisp environment where everything is
> compiled and just having a (require "SDL") is good enough. I had
> better take a look at your cl-ppcre package.

You should use LispWorks' Common Defsystem

  <http://www.lispworks.com/documentation/lw445/LWUG/html/lwuser-175.htm>

or an implementation-independent system definition thingy like ASDF or
MK:DEFSYSTEM.

Cheers,
Edi.


Re: ODE/SDL/OpenRM FLI bindings

Nick Levine <ndl@ravenbrook.com> writes:

> What I meant was that, in my experience, a 3.5MB LispWorks executable
> is unlikely unless it's not much more interesting than "hello
> world".

I have a 3.1MB LW executable (delivered at level 4) that talks to a
database, does some not _completely_ trivial calculations, outputs
latex source and calls out to pdflatex to create a nice looking
report.

It's not rocket science, but the users find it a bit more interesting
than "hello world" :)

It is started once for each report generated and terminates after
generating the pdf.  As it is invoked from a semi-public webpage and
runs on a busy webserver, startup times and memory footprint was
important considerations.

-- 
Mvh/Regards
Peder O. Klingenberg
Netfonds ASA


Re: ODE/SDL/OpenRM FLI bindings

Unable to parse email body. Email id is 5132

Re: ODE/SDL/OpenRM FLI bindings

Nick Levine <ndl@ravenbrook.com> writes:

> Most likely, you'll get better performance still (with or without
> delivery) if you keep the application running all the time. See, for
> example, the mod_lisp Apache module.

Yes, probably.  We do use long-running lisp daemons for a lot of
stuff.  We don't use mod-lisp, instead we have a library for letting
php pages talk to the daemons.

However, this particular program is only used to generate tax forms
for a small minority of our customers.  Even the customers who need it
only need it around the time of year when the tax returns are due.  So
it would be a waste to make it a persistent process running all year.

I did contemplate stuffing it into the daemon which handles the tax
stuff for the majority of our customers, but for various reasons (such
as allowing me to play with delivery options :) ) it ended up a
separate program.

-- 
Mvh/Regards
Peder O. Klingenberg
Netfonds ASA


Re: ODE/SDL/OpenRM FLI bindings

"Marc Battyani" <marc.battyani@fractalconcept.com> writes:

> Not to forget the on the fly pdf file generation with cl-pdf and cl-typesetting. ;-)

Yes, I've been meaning to take a very much closer look at those when
time permits.  However, we have a biggish body of code for handling
latex documents, and it predates both cl-pdf and cl-typesetting.  It
takes some effort to overcome the inertia. :)

-- 
Mvh/Regards
Peder O. Klingenberg
Netfonds ASA


Updated at: 2020-12-10 08:49 UTC