<div dir="ltr">Whilst I do not defend how we currently handle Python inside the BGE, I don't think that this is the best solution to fixing such problems.<div><br></div><div>My primary concerns are thus;</div><div><br></div><div>1. Bloat. Moving OO centric code from the objects they're concerned with to a generic interface both creates a heavy header to link against, as well as removes the OO paradigm of related functions with their concerned data.</div><div>2. Code duplication & Interface. This solution addresses two different parts of the Python API - where it is defined, and seemingly where it is being called from.<br><br>I prefer to look at the problem in a more generic manner. The current scripting problem is that Python is embedded in the BGE, which is undesirable (inflexible). In addition to this, We're still using partially user-defined bindings, instead of more extensible wrappers (see Panda3D's API generator). Addressing these two concerns makes things far more interesting to work with.</div><div><br></div><div>In a more general sense, there are quite a number of systems which assume a specific design paradigm, and once we start distributing out these systems the BGE may better have benefited from a more involved consideration for a redesign.<br><br>Nice work, nonetheless, you took your time to actually explain your ideas :) </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 January 2015 at 11:00, <span dir="ltr"><<a href="mailto:bf-gamedev-request@blender.org" target="_blank">bf-gamedev-request@blender.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Bf-gamedev mailing list submissions to<br>
<a href="mailto:bf-gamedev@blender.org">bf-gamedev@blender.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.blender.org/mailman/listinfo/bf-gamedev" target="_blank">http://lists.blender.org/mailman/listinfo/bf-gamedev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:bf-gamedev-request@blender.org">bf-gamedev-request@blender.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:bf-gamedev-owner@blender.org">bf-gamedev-owner@blender.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Bf-gamedev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. A new script interface for bge (in theory) (pgi)<br>
2. Re: A new script interface for bge (in theory) - A small<br>
diagram (pgi)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 28 Jan 2015 21:20:33 +0100<br>
From: pgi <<a href="mailto:pierluigi@tukano.it">pierluigi@tukano.it</a>><br>
Subject: [Bf-gamedev] A new script interface for bge (in theory)<br>
To: <a href="mailto:bf-gamedev@blender.org">bf-gamedev@blender.org</a><br>
Message-ID: <<a href="mailto:54C94491.1000902@tukano.it">54C94491.1000902@tukano.it</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
I hereby propose a new script interface for bge. I will also take care<br>
of it - once I figured out a couple of runtime issues with linking and<br>
resolving names. No coding needed, just ideas.<br>
<br>
Currently bge scripting is done in Python. To be clear, that's perfectly<br>
fine: it makes sense to have one scripting language - and not a hundred<br>
- and it makes sense for it to be Python.<br>
<br>
Here's the problem I see though.<br>
<br>
The interface between the engine and the scripting layer is spread all<br>
over the place. Each engine element has its own little subset of the<br>
whole thing. The thing is in fact so tightly integrated that changing it<br>
would be a major undertaking.<br>
<br>
Instead of doing that i made a couple of experiments with adding a new<br>
interface that will, with time, replace the older one. It can be made to<br>
work.<br>
<br>
This is how the new system would work - more or less.<br>
<br>
The engine presents itself to the scripting interface via a big<br>
collection of functions, much like an opengl interface. Things like this:<br>
<br>
class ScriptInterface {<br>
public:<br>
long findObjectId(std::string name) { ... }<br>
int getObjectType(long id) { ... }<br>
void setObjectLocalLinearVelocity(long id, float x, float y, float<br>
z) { ... }<br>
void getObjectLocalLinearVelocity(long id, float* buffer3) {<br>
...something... }<br>
...and so on forever and ever...<br>
}<br>
<br>
So it's a huge set of relatively small function, defined in one file.<br>
This is used by the scripting system to get data from the engine.<br>
<br>
The script layer is defined in a dynamic library, with a interface like<br>
this:<br>
<br>
void start(ScriptInterface* si)<br>
void tick();<br>
void stop();<br>
<br>
From the engine side, the scripting layer is then activated and ran<br>
like this:<br>
<br>
...when the engine starts:<br>
scriptlibrary = load_the_dll<br>
ScriptInterface* si = new ScriptInterface(ketsy, scene list, maps,<br>
whatever is needed);<br>
scriptlibrary.start(si);<br>
<br>
...for each frame<br>
scriptlibrary.tick();<br>
<br>
<br>
...when the engine quits:<br>
scriptlibrary.stop()<br>
unload the dll if necessary<br>
<br>
So there's very little to change in the actual code of the engine, and<br>
that little is just adding a couple of lines.<br>
<br>
What's in the dynamic library.<br>
<br>
In the jvm version:<br>
<br>
start(ScriptInterface* si) -> stores si, starts the jvm, load the jvm<br>
script interface (a java class, BGEScriptContext)<br>
tick() -> tick the BGEScriptContext, which in turn ticks all the scripts<br>
loaded on the jvm side<br>
stop() -> signal the scripts to stop, kills the jvm<br>
...<br>
one jni function for each ScriptInterface function, like:<br>
JNIEXPORT jlong<br>
Java_org_blender_bge_scripting_BGEScriptContext_findObjectId(JNIEnv*<br>
env, jclass cls, jstring name) {<br>
long id = scriptinterface.findObjectId(stdstringname)<br>
return id;<br>
}<br>
<br>
This is a trivial 1:1 mapping.<br>
<br>
The third part is this BGEScriptContext class, which looks like this:<br>
<br>
public class BGEScriptContext {<br>
static { System.loadLibrary(...the aforementioned dll...) }<br>
...for each ScriptInterface function<br>
...the corresponding static method, like<br>
public static native long findObjectId(String name);<br>
public static native void setObjectLocalLinearVelocity(long id,<br>
float x, float y, float z);<br>
...<br>
}<br>
<br>
Another long, boring but still very trivial 1:1 mapping.<br>
<br>
And that's it. Once you have this big java class in place, all the<br>
languages that run on the jvm can access the bge engine functions. You<br>
can have it in python scripts:<br>
<br>
import BGEScriptContext<br>
<br>
id = BGEScriptContenxt.findObjectId(name);<br>
<br>
in java, in scala, in lua, in javascript. More so, on top of the raw<br>
BGEScriptContext one can build a structured interface, without the need<br>
to interfere with the engine code. So one can have a Scenegraph type<br>
that gives the scripters access to BgeGameObject types (that the<br>
scenegraph will secretly build from ids).<br>
<br>
Advantages i see over the current system.<br>
<br>
From the engine perspective:<br>
<br>
1. the script interface is defined in one place, which makes it easier<br>
to maintain, extend and - in case of an excess of love - transplated as<br>
it is in case of radical upgrades to ketsji<br>
2. the engine doesn't have to know how the scripting interface runs, it<br>
just loads a dll and calls a total of four functions.<br>
<br>
From the scripting perspective:<br>
<br>
1. because of the dynamic linking, the script counterpart can be<br>
replaced (wanna pass from jvm to mono? Just create a new dll with the<br>
same load(ScriptInterface), tick() and stop() functions. Well, at least<br>
that how I think dll works.).<br>
2. using a proper virtual machine allows to support multiple languages<br>
with a single interface to maintain. That's for free. For the jvm, once<br>
you get that BGEScriptContext class in place, you can code in Python,<br>
Java, Javascript, LUA, Kotlin, Scala, Pizza, Prolog (there is still<br>
someone using prolog!), C, Pascal. Take that Crytek.<br>
<br>
And I sincerely hope this mail doesn't come back from the mailing list<br>
serve, flagged as spam, because it took me a long time to write it.<br>
<br>
I'd like to know if anyone has any thoughts on this subject.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 29 Jan 2015 02:31:22 +0100<br>
From: pgi <<a href="mailto:pierluigi@tukano.it">pierluigi@tukano.it</a>><br>
Subject: Re: [Bf-gamedev] A new script interface for bge (in theory) -<br>
A small diagram<br>
To: <a href="mailto:bf-gamedev@blender.org">bf-gamedev@blender.org</a><br>
Message-ID: <<a href="mailto:54C98D6A.5010908@tukano.it">54C98D6A.5010908@tukano.it</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
I have produced a diagram to help explain my mumbling.<br>
<br>
Here's the link<br>
<br>
<a href="http://www.tukano.it/blender/TheDiagram.pdf" target="_blank">http://www.tukano.it/blender/TheDiagram.pdf</a><br>
<br>
Diagrams are professional, so this idea becomes automatically a good one.<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Bf-gamedev mailing list<br>
<a href="mailto:Bf-gamedev@blender.org">Bf-gamedev@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-gamedev" target="_blank">http://lists.blender.org/mailman/listinfo/bf-gamedev</a><br>
<br>
<br>
End of Bf-gamedev Digest, Vol 15, Issue 5<br>
*****************************************<br>
</blockquote></div><br></div>