<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Btw i have a working prototype integrated so things are not anymore
in theory, now I know it also can work. That it also is a reliable
implementation of a clever design is much less certain. I can
provide a zip if that might help claryfing this thing. I'm not also
saying "hey, tomorrow we zap this thing in", it's a design
discussion.<br>
<br>
I understand the modular design of the engine and I do agree that,
in general, one big set of functions in a file is not a good idea.<br>
<br>
There is no concurrency in the diagram at page 2 (which apparently
didn't clarify things). Mixing uml notation with flow diagrams
probably didn't help much. Sorry.<br>
<br>
The system is fully sequential.<br>
The engine starts, instantiate an IScriptInterface, load the script
interface passing a pointer to it.<br>
It enters the main loop, for each frame it ticks the script
interface - which represents the logic update pass of the engine.<br>
The script interface ticks the scripting units.<br>
Each unit does what it needs, if it has to get or set data used by
the engine, it does so by calling (directly or, as I think should
be, using an oo api built on top of the low level IScriptInterface).<br>
After the last script unit has been updated, the green thing, the
script manager, returns the control to the engine.<br>
The engine completes the current frame and starts another loop.<br>
<br>
I like the door metaphor and the way I see it is that the big chunk
of functions is the door between two rooms. You take out that and
you have big one badly shaped room.<br>
<br>
I can't fathom how you don't see the definition of the script
interface inside the code of the engine components as a gigantic
problem because it is, it is not a feature, it is a design flaw.<br>
<br>
I think that providing the engine with a unified scripting interface
is a sensible design choice because of the benefits of decoupling.<br>
<br>
And the big file also addresses documentation problems. It's one
place for one task.<br>
<br>
I agree that the api might need smaller fixes and there is for sure
a lack of documentation but fortunately I have enough experience to
know where exactly the engine is lacking and I also know what can be
done about it, so I'll do this instead.<br>
<br>
<div class="moz-cite-prefix">On 29/01/2015 19:43, brita wrote:<br>
</div>
<blockquote
cite="mid:CAHaG9azvMk2PhW5t6ZAsqHwoWvb6TdqTeZcdkCnZ9CVgyPQeRg@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_extra">Skimming through your text and
diagrams..</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">you are attempting to provide 'one big
file with the API', instead of the bits, as is now.</div>
<div class="gmail_extra">One big file is seldom a good idea and,
in this case, the BGE is designed in modules and objects. The
python API reflects the Object Oriented programming that is
inside. It should be modular and in bits, it is intentionally
designed this way. OpenGL is designed in a different way.</div>
<div class="gmail_extra">this means that you shouldn't do
function(objectid, args), but object.function(args)</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">next, you are splitting of the API from
the engine into a separate shared library. why? (and take
care, because dlls are the windows version of shared
libraries, blender is multi-platform).</div>
<div class="gmail_extra">the API is a door to interact with a
system. doors should be provided along with the room, they are
a part of it.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">the third thing is your focus on start,
tick, stop.</div>
<div class="gmail_extra">The GE loop currently is not prepared
to be controlled externally.</div>
<div class="gmail_extra">Look at your diagram in page2, you have
concurrent arrows, who controls the call of a next frame?</div>
<div class="gmail_extra">Is it even useful to control it
manually?</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">all this said, the python api for the
ge is incomplete and has many things out of place.</div>
<div class="gmail_extra">as a suggestion, why don't you try to
fix smaller things in the current API, starting by lacking
documentation, if you will. until you have enough experience
to know where exactly it is lacking and what you can be done
about it.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">--</div>
<div class="gmail_extra">Inês Almeida / brita_</div>
<div class="gmail_extra"><br>
</div>
</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>