Yasha

The object is created on the C++ heap. Different wrapper functions return C pointers to C++ objects (how these are translated into values of your language depends on how the FFI handles returned C values; a high-efficiency FFI probably wouldn't create anything on the client language's heap at all). So when you call a wrapped method such as the one in the example, you're just passing back to C++ a pointer that originated from C++ in the first place. DLL functions can't just have the tail parameters. This doesn't make any sense at all! How would the method operate on an object if it never receives any object reference? (C functions operate at a lower level than what you might be used to from a language like Smalltalk: functions are just static vectors of machine code, they cannot retain references to nonglobal values - the object must be passed in, either as a parameter, or through the syntactic sugar that is C++ method call syntax.) Functions such as the above - with the C++ object pointer as the first parameter - are exactly what you need for a language binding, to remotely manipulate objects located entirely within the C++ layer.

Guards = #if 0 ... #endif around things you don't need. Leadwerks_G.h is my own doing: after sticking in a bunch of said guards to get rid of unwanted things like the standard libraries, run it through gcc -E to include all files and expand all macros, creating a "flat" Leadwerks header. This is not necessary to use SWIG in the general case (SWIG is built on GCC anyway, it can do preprocessor stuff perfectly well), but it gave a clearer idea of what was going on, I thought. SWIG produces C-style code like this: EXPORT void _wrap_Entity_Translate__SWIG_1 (Leadwerks::Entity *larg1, float larg2, float larg3, float larg4) { Leadwerks::Entity *arg1 = (Leadwerks::Entity *) 0 ; float arg2 ; float arg3 ; float arg4 ; arg1 = larg1; arg2 = larg2; arg3 = larg3; arg4 = larg4; try { { (arg1)->Translate(arg2,arg3,arg4); } } catch (...) { } } (Longwinded to read but will be identical to a one-liner after optimisation.) That's what is found in Leadwerks_wrap.cxx: C-style wrappers for C++ calls, creating a completely flat API. I assume this also answers the question about heap usage (which I otherwise don't follow, sorry). It also produces FFI declarations for the requested language to make these C-style wrapper functions available. How much more wrapping takes place at that level depends on how that language's FFI works (the CFFI output is nice primarily because it consists entirely of easily-parsed type declarations - I assume a Common Lisp interpreter will build glue out of these itself - rather than actual C glue code to do the dynamic type checking like it outputs for some other targets; this means you can extract the types for other uses).

Did you look at SWIG, mentioned on the previous page? ( http://www.swig.org/ ) It wraps C++ classes from languages with an FFI (sorry to burst the "cannot be done" bubble). If you can get it outputting something your language can understand you shouldn't need a C-style DLL at all. Leadwerks.h requires a small amount of tidying in order to work with it, but the main API does export correctly once you've put the right guards in place and so on. If your language isn't supported directly, SWIG can dump a full parse tree in Lisp format which you should be able to pass through a second layer to process into declarations for the thing you want to use (or maybe one of the others will be close enough; I found the CFFI backend gave all of the necessary data in a much smaller file). e.g. put this together in a couple of minutes: https://dl.dropboxusercontent.com/u/46635275/SWIGtest.zip (Leadwerks_G.h is a preprocessed version, only contains limited declarations for export, skipping the irrelevant and the difficult; Leadwerks_wrap.cxx is the generated C-style library; Leadwerks.i is the interface definition that passes the original header to SWIG; the Lisp files are the generated CFFI output.)

The eye is not a monitor with a fixed clock, the receptors don't all have to update at the same instant. Some update while others rest. 10 FPS is also the lower end of a sliding scale.

I would add my voice to Christian Clavet's in expressing interest in retained access to 3.0 for mobile (assuming it works as advertised). Porting PC code to an older and unsupported version of Leadwerks has still got to be better than porting it to a completely different engine, at least to get something started. (I was one of the people foolishly deciding to wait for 3.1 and the Kickstarter to complete before buying mobile support... oops.)