From: Richard R. <sf...@ol...> - 2003-12-17 05:04:43
|
On Wed, Dec 17, 2003 at 12:41:38AM +1100, Nigel Stewart and Fiona Smith wrote: > >I think that networking is desirable for one real reason: > > We were recently kicking around another reason for > integrating networking into the GLUT world-view: > Collaborative applications. [...] Sounds fun. (^& > > * Threads: This might work, run one thread in GLUT and another to talk to > > the network. My understanding is that thread portability is a bit > > touchy. > > This works for me nicely in C++ using the ptypes library: > http://www.melikyan.com/ptypes/ Hm. Looks interesting. Thanks! > I've had threads talking to webcams via HTTP passing decompressed > JPG data back to the GLUT event loop. Crude, but fine for > a basic form of tele-presence. > > I'm also aware of many ugrad student projects mixing GLUT > with socket-level code for multi-player games. It's not easy, > but it's been done. If you forego your own select() and use an idle or poll, that shouldn't be too hard, should it? (Go with non-blocking I/O, of course...) Am I missing something? (What is the saying? Nothing is ever too hard if you don't have to do the work. (^&) > >It's not a high priority item, but it's a useful extension, IMHO. > > The simple facility to feed keyboard and mouse events between > GLUT applications is by itself a useful thing. A general > purpose message-passing scheme may just about nail it, > for lots of multiplayer scenarios, I think. Okay. I assume that DNS lookups should be done, rather than forcing users to rely on IP numbers. I assume that TCP type connections must be provided. I assume that UDP *may* be desirable. I assume that inbound data would come in callbacks. Would messages be wrapped in some special container when put into the network? Would you get some kind of reply? Would a message's reply (or a whole socket) be attached to a window? -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |