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

[Paul Pogonyshev <pogonyshev gmx net>]

Niko Demmel wrote:
> 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.

My rule of thumb is like this: if you have a job that might take a lot of
time (in your case "a lot" may be 0.05 seconds if you need to avoid even
short freezes), and it is cumbersome to spice it with break points to run
accumulated events in the queue, you need a thread.  Otherwise, you don't.
E.g. if you have a loop that runs 1000000 times, it is trivial to execute
pending events e.g. some 1000 cycles.  If your job is hairy and have 10
nested loops with no clear time separation, better use a thread for it.

> [...] 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!).

It should be possible to do anything that doesn't insist on using own event
loop in the main thread, just use a custom event source if needed.  Even
some event loops can be mixed with GLib event loop, AFAIK.

> 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).

Well, that is more about clean job separation and interfaces than about
threads.

> > 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.

Hm.  In the thread you add a handler with bound data.  When it is invoked
in the main thread it emits some signal with that data.  You probably need
one dispatcher per such message, but they use only one internal pipe no
matter how many dispatchers you create, so this shouldn't be a problem.

But frankly, has been some time since I use GTK+ in C++.

Paul