[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scripting



Gregor Mueckl wrote:

> My best computer is a P-III 500Mhz, which is even slower (and I'm not
> even considering an upgrade yet; other computers in my home network will
> be more urgent - like my good, old 486 Linux (file-/ YP- /Samba- /DNS-
> /whatever-) server). And yes, it can do compilation rather fast. But
> with a new binary there also is the need to restart the game engine (or
> engines in case you develop a networked game as I do). With a script you
> might avoid this.

OK - for the third or fourth time in this thread...

   *NO* you don't need to restart the game engine to change out
   a 'script' that's written in C or C++.

This isn't an opinion, I have major applications that work this way.

Since this message clearly isn't reaching some people, I deduce that
many of us have not typed:

   man dlopen

Here is what you do to have scripts written in C/C++ and have them
replaced WITHOUT RESTARTING THE GAME:

  * Compile your 'script' into a ".so" library, let's suppose for the
    sake of argument that every script will contain two external
    functions: 'initialise' and 'update'.

  * Compile your main program without calls to any of the
    scripts - and without linking to them.

  * In your main program you can write things like:

    void (*init)() ;
    void (*update)() ;
    void *handle ;

    handle = dlopen ( "myscript.so", <someflags> ) ;
    init   = dlsym ( handle, "initialise" ) ;
    update = dlsym ( handle, "update" ) ;

    ...which loads in 'myscript.so' at runtime - not when the
    program was linked or when it started running.  The loading
    of this library into RAM only happens when you call 'dlopen'.
    The two 'dlsym' calls look up the addresses of the two external
    functions that were in your script.

      (*init)() ;   /* Initialise the script */

    ...and in the main loop:

      (*update)() ;

  * Notice that you can have many scripts loaded at the same time
    (just make 'handle', 'init' and 'update' be arrays and do separate
    dlopen and dlsym calls for each script) - it doesn't matter that
    all the scripts have external functions with the same names.

  * So, at some time into running the game, you decide to change one of
    the scripts.  So - without ending the game - open an editor, change
    the source code for one of the scripts and recompile it into a
    '.so' just as you'd do if the game wasn't running.

  * Since the game is still running, you can have it set up so that
    hitting a magic key causes it to run:

    dlclose ( handle ) ;
    handle = dlopen ( "myscript.so", <someflags> ) ;
    init   = dlsym ( handle, "initialise" ) ;
    update = dlsym ( handle, "update" ) ;
    (*init)() ;   /* Initialise the newly loaded script */

    ...the dlclose tells Linux that your main program wishes to be
    UNLINKED from the old copy of the script library that's in RAM...
    then it can relink to the new version using dlsym and pick up the
    new addresses for those two external functions.  Initialising the
    new script completes the action.

So, you can actually edit and recompile parts of your program WHILE
IT'S
STILL RUNNING!!

This isn't unique to Linux - most UNIX'en have dlopen.  I believe there
is a similar mechanism with DLL's under Windoze - although the API is
subtly different.

There are also some options to dlopen that I skimmed past - these allow
the physical attachment of the library to your executable to be delayed
until you actually call one of the functions...well, something like that.
I recommend using 'RTLD_NOW'.  You can also make symbols within your
library available to other dynamically loaded libraries...but that gets
messy fast - so don't go there!

> This might be beneficial (and good for ones nerves) if
> it's tiresome to get to the point where you can actually test the new
> code after an engine restart.

...and there is no reason not to do it in C/C++.

Of course if you are DEBUGGING some buggy script code, a bug in the
script could still crash the application...but that's life.

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net