Re: game programming

[Andreas Jellinghaus <aj dungeon inka de>]

> I solved it entierly different than you suggested. Instead of using two
> threads, I use two orinary processes wich communicate over CORBA.
> 
> So you specify the interface of your gaming engine in CORBA-idl and
> implement it as CORBA-objects. Then you let your GUI communicate with
> your gaming engine.

hmm. but if the GUI is "the master", it need's to poll the game engine
"is there anything i can do for you ?". how can i do that
(preferable, without rewriting whole gtk_main) ?

> Whether or not this approach is better than yours depends on things like
> how complex your interface to the gaming engine is, and several other
> things.

both solutions are fine - polling from the game engine, or pushing via sending
some signal or so, both is ok. basic thing is :
i don't know what gtk_main does. and i guess it has an awfull long list of
things that it does. and i need to add one thing ...

how can i communicate with the gui thread/stuff/object/... ?

hmm. evil idea: maybe it's possible to send some stuff to the x server,
and get it back (send by the game engine, got back by the gui) ?

> But think about it, since you get additional benefits from it, like instant
> multiplayer support over network (IIOP) and easy portability to other
> environments, such as KDE/Qt. And you have clean seperation between the
> GUI-code and the engine, things that are bad to mix up anyways.

oh, the separation is easy. i'm still amazed how i could put everything into
451 lines of tcl/tk code... the current c version is 300 lines long, only for
a very rudimentary stuff, the whole game engine is missing ...

andreas