Paul Pogonyshev wrote: > > Hm. Why do you need all the threads at all? You should be fine with one > and one is times easier to implement than many. If you need to receive > some non-standard events, e.g. from your network, you can subclass > Glib::Source. Or just use existing Glib::IOSource, it is sufficient in > many cases. > Thinking about it now, you might be right.
I initially started out with my first program which was multithreaded and just playing with Gtkmm. I had the game working but my design of game logic and GUI was totally intermixed and it soon was too messy to maintain or even expand. So since I now knew about most of the GUI stuff, I decided to rethink the design and thought it would be best to have threads for networking and game logic (responsive GUI...). But since I now am back (without realizing it initially) to where I started, namely putting the game logic in a timer callback I might aswell put it in the same thread as GUI. And since you say the networking can be done this way aswell (I will look into it, but I want to get to game going non networked first anyway) I should be fine without extra threads (yuhu!). The only thing i need to do is design the game logic and the gui cleanly and seperately almost as if they were in seperate threads so I can easily export or substitute one part (e.g. server for gamelogic or client with AI). Thank you for poitning that out. It probably will save me lots of trouble. > Use sigc::bind. Again, I think you can get away without Dispatcher in > the first place. > Doesn't work. I only can bind at the receiver end, but not send values through from the sender thread. What I want is to e.g. invoke a signal request_player_direction(int player_id, eDir direction) in another thread and - most importantly - pass different values to it every time i call it. With bind you fix the value for the parameters for all calls. But as you pointed out I probably won't need cross thread signals any more, so sigc++ does the job. Niko _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
