Re: game programming
- From: Andreas Jellinghaus <aj dungeon inka de>
- To: Stefan Westerfeld <stefan space twc de>
- Cc: gnome-list gnome org
- Subject: Re: game programming
- Date: Mon, 24 Aug 1998 22:34:41 +0200
> 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
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 ...
] [Thread Prev