On Jan 13, 2008 4:01 PM, Duncan Coutts
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.