<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On a more general scale, what I would like to do - and I'll be
shameless enough to propose right after the conclusion of the next
dev irc meeting - is this.<br>
<br>
1. come up with a new design for the engine<br>
2. refactor the current system to constrain it into the new design.
A pure refactoring of the code, no functions added or removed, just
moving stuff. From the perspective of the user, the program will
still work exactly as it did before.<br>
3. upgrade the subsystems where needed.<br>
<br>
At that point things start to change.<br>
<br>
I believe it is possible because I'm reading a lot about game engine
design lately and they have a common core that maps more or less to
ketsjii. In fact the scripting part is the only one I can't fit in
because there is not this unified scripting interface.<br>
<br>
I confess that I don't see the current mapping of script functions
to object members as a benefit, not even from a design perspective.
Each object has two interfaces, defined in the same place, for
different purposes.<br>
I'm not saying that scripts would have to be written using the set
of functions defined in the headers, not at all. Once you get rid of
the python interpreter you can reconstruct the current object based
api, in the same way game engines are built on top of the opengl
interface, using the "native" language of the vm (C# or Java but I
would choose the jvm because it is gpl).<br>
<br>
Code duplication is a bad bad bad by product of my proposal. I can't
get rid of it. In fact, in the prototype I have, the same set of
functions appears not two but three times.<br>
Once in the header, once in the engine and once in the dll.<br>
I didn't try but I think I could get rid of all three layers but in
doing so I would tight the engine to the scripting vm, repeating the
same mistake (I can't help but seeing it like that) that has been
done with the current api. And you don't really want to have JNI
code in your engine objects.<br>
<br>
I'll look into Panda3D API generator. As a side note, my problem
with python is not really a problem with python but with the
question: how do I run those scripts on android?<br>
<br>
<div class="moz-cite-prefix">On 29/01/2015 19:58, Angus Hollands
wrote:<br>
</div>
<blockquote
cite="mid:CAOU6hw5GvurKo3uxbnsDFNb36jWeGAxZgtaRVMxvwkXL-XgdMg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:pierluigi@tukano.it">pierluigi@tukano.it</a>><br>
Subject: [Bf-gamedev] A new script interface for bge (in
theory)<br>
To: <a moz-do-not-send="true"
href="mailto:bf-gamedev@blender.org">bf-gamedev@blender.org</a><br>
Message-ID: <<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:bf-gamedev@blender.org">bf-gamedev@blender.org</a><br>
Message-ID: <<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Bf-gamedev@blender.org">Bf-gamedev@blender.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-gamedev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-gamedev@blender.org">Bf-gamedev@blender.org</a>
<a class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-gamedev">http://lists.blender.org/mailman/listinfo/bf-gamedev</a>
</pre>
</blockquote>
<br>
</body>
</html>