[Ecls-list] embedding ecl into a game engine

[Ilya Kliot]

Thanks a lot for the answer, each mail in this thread opens my eyes
wider and wider and
I'm getting closer and closer to the final result. I will send a link
to the installable demo
at the end - it will allow to use ecl together with 3D, 2D and sound
environment similar
to the impromptu.moso.com.au with little bit less prepared audio controls :)


On Sun, May 17, 2009 at 4:18 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> On Sat, May 9, 2009 at 3:19 AM, Ilya Kliot <plushe at gmail.com> wrote:
>> Anyway let me clear a picture. The starting process is an engine,
>> all the objects (instances)  of the engine organized into a tree at
>> runtime - like a file system, so all the time
>
> Ok. That makes things easier: objects have names, which are strings.
> This will save you a lot of coding.
Exactly - each instance is identified by path in objects instances
tree like "/usr/scene/bear" for animated bear or  "/sys/servers/gfx"
for render server.
>
>> there is some object that is current for the script interpreter, like
>> cwd. Each class can export some
>> methods to general script interface facility, exactly as you wrote -
>> some hash tree that keeps the commands
>> and the args. After engine starts it loads an appropriate script dll -
>> in ecl case by cl_boot and
>> injects few basic functions like : new , delete, sel(like cd in fs),
>> psel(like pwd), exists etc.
>
> So far fine. You just have to code a number of functions that wrap
> around the  C equivalents.
Yes and I did it. Still got no ecl module running, but I suppose that basic
 functions like "new" "delete" etc. are ready. Here is a "new" code for
instance:
//------------------------------------------------------------------------------
/// Convert a lisp object into its string representation.	
stl_string nEclServer::to_string(cl_object obj)
{
	cl_object princed = cl_princ_to_string(1, obj);
	return stl_string((char*)princed->base_string.self);
}
//------------------------------------------------------------------------------
///    eclcmd_New
cl_object eclcmd_New(cl_object class_name, cl_object name)
{
    if (ecl_stringp(class_name) && ecl_stringp(name))
    {
        nRoot* o =
nEclServer::kernelServer->NewNoFail(ecl_base_string_pointer_safe(class_name),
ecl_base_string_pointer_safe(name));

        if (o)
        {
            return ecl_cstring_to_base_string_or_nil(o->GetFullName().c_str());
        }
        else
        {
            FEerror("Could not create object ~A of type ~A ~%", 2,
                        nEclServer::to_string(name).c_str(),
                        nEclServer::to_string(class_name).c_str());			
        }
    }
    else
    {
        FEerror("Invalid parameters to new ~A ~A ~%", , 2,
                   nEclServer::to_string(name).c_str(),
                   nEclServer::to_string(class_name).c_str());		
    }
    return Cnil; // return false in case of failure
}

>
>> Those functions should operate with engine functions  and data at
>> runtime. I thought that
>> I can achieve this by def_c_function(...).
>
> Yes.
>
>> Are those samples, mine and one you provided, equivalent from this
>> sight ?
>
> Yes, the only difference is that I coded this in a lisp file. You can
> embed C code in lisp and then compile it using ECL.
Ok, I should probably advance to it at some moment.
>
>> And which function from
>> externals.h corresponds to "(error "Could not create object of type
>> ~A" class-name))" this statement ?
>
> Every lisp function has a C equivalent. In this case it is
> cl_error(int narg, cl_object arg1, ...) but this time there is a
> simpler C equivalent FEerror(char *message, int narg, ...). It would
> be something like FEerror("Could not create object of type ~A", 1,
> class_name);
>
>> But I really will glad to
>> help to comment or to document the externals.h because I still got no
>> which functions are right to call for string conversions from c to ecl
>> and vice versa. I found several, but which call when ?
>
> The reason why this is not well documented is because most people use
> the Lisp foreign function interface and not direct coding of C. But
> your answer is is simple
>   cl_object make_simple_base_string(char *data)
>     makes a Lisp string using the text you provide
>   cl_object make_base_string_copy(const char *s);
>     similar, but it first copies the data
>   cl_object c_string_to_object(const char *s);
>     this is a completely different beast: it parses a string and
> reads an arbitrary lisp object.
>     For instance, c_string_to_object("1.0d0") would return a lisp float
Excellent. It answers to many questions ...
>
>> To provide this general proxy
>> I can write some general function that will receive command and args,
>> but it's not too elegant solution at my
>> opinion. If I can't get command and args in "unknown-function" so may
>> be I can export the engine object
>> into lisp in some way ?
>
> Well right now the first option seems to be the only one. If you want
> you can modify the Lisp reader to make it more attractive. You can
> customize Common Lisp so that something like @(method arg1 arg2 ...)
> or {method arg1 arg2 ... } is translated into (engine-call-method
> method arg1 arg2 ...) where "engine-call-method" is the function that
> looks up the hash.

ok, this is what I'm in process now and even the form you proposed is very
well for it, I mean it will be good that engine commands will be
prefixed in some way
to make it easy to distinguish them by eye, I will look for the way to
implement it
in such form.
Thanks again
Ilya
>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28009 (Spain)
> http://juanjose.garciaripoll.googlepages.com
>
>