sritchie@cs.ubc.ca (Stuart Ritchie) (03/25/91)
Hello again netters, first I must extend my thanks to William
Shipley (sp?) for his swift and helpful answer to my "hit test"
question a week or so back. (The answer was to use the magical
Display PS function infill... nice stuff, but boy I bet it sure
sucks those MIPS...)
This time I wondering if it's possible to open windows on remote
machines. No, I don't mean the -NXHost stuff. What I'm thinking
about is having a program run on my machine, let me interact with
it locally (via windows, duh) and also open windows on other
machines. Sort of like -NXHosting individual windows of an
application.
I suppose I could use the client/server model, but that would
involve at least two separate applications. I want one app
to display and receive events from many machines.
---
There's some intersting stuff happening with Mach 3.0 these days.
(not to mention BSD4.4...) I wonder how closely NeXT will pursue
new OS technology... maybe now that they have a stable Unix
platform there's no need to go off on a risky tangent.
---
Now the important stuff. How about full screen BoinkOut? Forget
this teeny window stuff...
_______ ______________________
\/ \
Stuart | Wot's... uh the deal? |
_______/\______________________/aozer@next.com (Ali Ozer) (03/25/91)
In article <1991Mar24.231657.21573@cs.ubc.ca> Stuart Ritchie writes: >Now the important stuff. How about full screen BoinkOut? Forget >this teeny window stuff... Hmm, if you think BoinkOut's window is "teeny," wait till you see BlastApp... BlastApp is a freely distributable game available on nova.cc.purdue.edu (in pub/next/2.0-release/binaries, as BlastApp.tar.Z). This is your basic "blast everything in sight" game. It runs on NeXTstep 2.0 and pretty much requires an '040 system (some levels are too slow on an '030). Color also helps but is not essential. Enjoy! Ali, Ali_Ozer@NeXT.com
wjs@milton.u.washington.edu (William Jon Shipley) (03/27/91)
Stuart Ritchie writes: >Hello again netters, first I must extend my thanks to William >Shipley for his swift and helpful answer to my "hit test" >question a week or so back. Aw, shucks. >This time I wondering if it's possible to open windows on remote >machines. No, I don't mean the -NXHost stuff. What I'm thinking >about is having a program run on my machine, let me interact with >it locally (via windows, duh) and also open windows on other >machines. Sort of like -NXHosting individual windows of an >application. > >I suppose I could use the client/server model, but that would >involve at least two separate applications. I want one app >to display and receive events from many machines. I played with doing this a while ago when developing a multi-user game. My first thought was to open multiple connections to different window servers on different machines, using DPSCreateContext. The problem with this is that apparently there is a global in the NXApp object that tells the AppKit which context to write to, so you'd have to do a bunch of kludging to get the AppKit to write to any connection other than your main connection (to your machine). (I never bothered trying this.) The other solution, which worked, is to start up a program and then BEFORE YOUR NXApp OBJECT INITS declare some shared memory and fork off a bunch of copies of your program, each of which has the NXHost preference set to a different machine. Then start up NXApp in each of the forked copies. This works. You get a bunch of NXHosted programs appearing on different machines, which have a nice area of shared memory to speak in. You can even kludge this a bit by declaring the memory as a zone before using it, so that you can allocate new objects in this zone. The problem with this approach is that you must decide how much memory to allocate before you fork. Note that another intuitive approach would be to just have mulitple NXApps in different threads in the same task. No dice, the AppKit expects one and only one NXApp. Kinda bummin, that. BTW, the method I ended up using was none of these: I simply have as many copies of my program running as I have users, and trap all messages any user sends, copying the message and sending it to all the other programs. This works nicely for a well-defined set of inputs. -william shipley