Re: Design for a game with Gtkmm as GUI and GLibmm for threads

[Niko Demmel <niko demmel gmx de>]

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