[Ecls-list] embedding ecl into a game engine

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Fri May 8 17:07:20 UTC 2009

On Thu, May 7, 2009 at 12:34 AM, Ilya Kliot <plushe at gmail.com> wrote:
> The last problem I have to complete
> the embedding is to provide automatic proxy to methods of all the engine
> objects supporting  a general script interface.

I am not really understanding what you mean here because I do not
understand what you mean by unknown method or script interface.

The only thing I can guess is that you do not want to define proxy
functions for _all_ functions in the game engine, but rather only as
they are needed. For instance, say the engine provides a "draw"
function which is available but the code has not been exported to Lisp
-- that is, there is no "draw" function defined. You might want to
intercept that error, lookup in some table and call the appropriate
engine function with the arguments that were originally passed to the
undefined function.

The way this works in Common Lisp is that when a function is not
defined a condition is signaled. It is like an error but with more
information. Right now the undefined-function condition does not have
a lot of information and it only generates an error. One might think
on tweaking ECL so that it adds more information: actual function
name, plus all arguments, so that you could conceivably do something
like with TCL: call some general proxy function that decides which
engine function to call.

Even though it would be really a good idea to change ECL to support a
better undefined-function condition, I would not vote for relying on
that for simplifying the FFI (foreign function interface). It would
lead to horribly slow code.

I would rather suggest you to use the code generating possibilities of
Common Lisp to automatically generate wrappers for all functions in
the game engine.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)

More information about the ecl-devel mailing list