[Haskell-cafe] MonadPrompt + Gtk2Hs = ?

[Felipe Lessa]

On Jan 13, 2008 4:01 PM, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> On Sun, 2008-01-13 at 14:53 -0200, Felipe Lessa wrote:
> You could use another thread :-)

LOL, at first I thought of mail threads =).

> That is have an output thread that reads a queue from your game engine
> and only looks for the next output message at appropriate points.

I'll comment on this shortly.

> Are you linking using -threaded or not? If not then you need another
> trick to use cooperative scheduling between Gtk and the RTS.
[snip]
> You must not be using -threaded then I'm guessing. That'd solve the
> problem.

Actually I tried with all combinations of -threaded/not -threaded and
forkIO/forkOS. I'm using an uniprocessor, but a simple turn-based game
shouldn't depend on dual-cores anyway =). Yes, those freezes do seem rather
strange, and when I introduced some (unsafePerformIO . putStrLn) with the
wall time they magically disappeared. I didn't try to pursue those little
insects further because I got the feeling that no mather what, they would
come back.

> > [...] using 'mainIteraction' [...]
> That's pretty ugly. I'd avoid that if I were you.

Yes. =)

> Here's my suggestion: use two threads. One thread for the game logic and
> one thread for communicating with the user interface. Then use an input
> an output channel to post interesting events between the two. The GUI
> would then also post interesting events into the incoming channel for
> the view/ui thread.
>
> Of course you'd have to link using -threaded and use postGUISync/Async
> as appropriate from the view/ui thread.
>
> By serialising all button events into a channel it allows you to ignore
> button presses that happen at certain moments. And as I suggested above,
> it allows you to serialise the output events so you don't end up showing
> several dialogues to the user at once.

It seems to be a nice idea. I worry about intermediate states that shouldn't
be observable (in my game the inputs the user is allowed to give change over
the time -- it's a board game, so which pieces can move vary according to
the current board), but what concerns me more after that bad experience with
only one forked thread are the delays between the user giving an input (e.g.
moving a piece) and the feedback being given (an animation of the result).
The chain would be something like

input given  -->  processed  -->  new board created  -->  shown
    (1)             (2)                 (3)                (4)

So the interaction between the threads would be

gtk:   (1) ===\                                     /===>  (4)
channel:       \===\                           /===/
runPromptM:         \===>  (2)  ===>  (3)  ===/


I'll try to code that ASAP and see how everything works together. If I do
observe the same delay problem, I'll try to at least reproduce it on another
machine and maybe create a simple test case.

Other than that, I'm surprised you didn't comment about the last solution,
as that's where I'm currently heading. =)

Thanks for the reply,

-- 
Felipe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080113/46cde269/attachment.htm