[Pharo-users] Memory mapped files and Pharo (aka Unreal Engine 4 integration with Pharo)
kilon.alios at gmail.com
Mon Jan 18 05:38:29 EST 2016
the way I see it at least, polling is not a problem, Graphics work on frame
loop, that means actions that have to repeat per frame , Unreal objects are
constructed around this functionality , same way we have a World cycle that
drawOn: methods work , then of course you have event loops etc. A signal
mechanism would have been a callback functionality but frankly I dont think
its necessary. My goal is to bring unreal closer to pharo , so that means I
will use similar functionality to Morphic and Bloc for drawing to make easy
for pharo guis to port to unreal because unreal is not only capable of 3d
but also 2d graphics.
So the idea is when the frame loops starts , execute first what Unreal has
to execute , then read a message qeue where pharo will register messages
very similar to pharo messaging . I may allow Pharo to assign messages to
specific frames. Those messages will call functions/methods of the Unreal
API. Of course it can work vice versa so that Unreal becomes aware of the
Pharo enviroment and callback pharo mehods etc and even Blender methods
(for asset creation) and I could even hook on this message que many other
applications essential to build a common language that apps and libraries
can talk to each other without depending on specific implementation and
Thats the general idea , so far, open to redesign and rethinking depending
on the obstacles I may face.
On Mon, Jan 18, 2016 at 10:14 AM David Allouche <david at allouche.net> wrote:
> > On 17 Jan 2016, at 22:18, Dimitris Chloupis <kilon.alios at gmail.com>
> > Pipes are actually slower than sockets (local UNIX sockets that is) and
> I dont need sockets if I am using shared memory.
> > I could create an event que and not allow direct access to shared
> memory, this way I make sure everything happens in order and in sequence.
> This way I can make sure multiple writes and reads dont happen at the same
> time. This could be a first implementation and if the need arises for multi
> threading then I can revise this design but frankly I rather stay away from
> multithreading and other complexities and keep this simple and easy to
> learn and code.
> You will still need a signalling channel so either side knows that it has
> new commands to process without having to poll.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-users