Re: the Zell solution ... it works!
Re: the Zell solution ... it works!
- Subject: Re: the Zell solution ... it works!
- From: Lou Zell <email@hidden>
- Date: Tue, 10 May 2011 13:36:21 -0700
On Tue, May 10, 2011 at 12:12 PM, JP May
<email@hidden> wrote:
I mean realtime control (via some sort of moving device: a knob, mouse, Wii controller or similar) of computer things - via wireless.
Hence, exact examples of this are your wireless mouse, all Wii games, and iPhone device-to-device games such as "Chopper" "Scrabble" etc.
> but your best bet would be probably UDP networking via CFSocket if you don't care about losing data.. Asynchronous TCP networking via CFSocketStream if you do care about losing data.
You know, at first I thought "oh UDP". the interesting thing is though if you try both, it's just not clear that there's any advantage at all.
JP, my app is one of the game controllers in the store - this stuff is right up my alley. Earlier you mentioned you used AsyncSocket. That is what we started with as well, but there would (very) occasionally be a delay on button presses. Looking at Wireshark this would usually occur on a TCP retransmit. Switching to AsyncUdpSocket actually produced a noticeable difference for us. Of course, the trick is not caring about a dropped packet (in my testing, it doesn't even seem to happen very often though).
Say you have a wireless controller for flying an aircraft
(I mean an actual aircraft, a Boeing 747 ... let's say the pilot's "Manette" n the arm of his chair, is wireless to the flight deck computers).
So say you have that -- what would you send? Only updates? Continuous everything? Or ?
I just don't know man. It's tough!
I find a combination of both works best. We use a timer to send out the state at 50hz, and also send immediately on state changes. So, say your state change packet gets dropped, the client will only have to wait another 20 ms tops (well, provided there isn't another drop) to get the updated state.
Related, we are working on this type of stuff pretty aggressively, and
in the not-yet-officially-announced Joypad SDK we make it possible to
drop controller components onto remote iPhones and get realtime updates
from them. I'd love to have some of you guys doing related things try
out the alpha. Email me off-list if you're interested! /plug
amazingly, down to about 18 hz per channel it still honestly feels flawless.
We were able to run it at 500 hz (!!!!!) (I write lean code!) with the fastest ipad/fone hardware,
and as a player I could not really say there is much difference. MAYBE 70 or so, I got an impression, is about the highest you could perceptually feel it is better than lower speeds. It's really interesting.
Good tip.
My latest ZELL TECHNOLOGY networking is wonderous, but, it's not like a mouse, I don't think ... I dunno.
Glad to hear it! Also, we've got mouse movement at 50Hz through a LPF and I must say it is pretty damn smooth. Maybe switching to UDP will make up the difference for you?
Anyway, I want to get in to adaptive framerates,
to counter problems like too many people joining a game, you have to throttle down the handsets in that case (I guess). (If you reach apparently about "500hz" on an iPad2 !)
Also depending on how crap the person's wifi hub is.
Here's an idea to get around adaptive framerates - although, I have no idea how well it will work in practice. You shouldn't need your iPad reading at 500hz, because you are only interested in state updates of each controller at 40hz. So if each controller was responsible for sending its state to only 1 peer, and that peer appended the state to its own state and transferred that to the iPad, you already cut your iPad reading frequency in half. Depending on how long the hops take, the controller at the start of the chain could feel sluggish. Maybe you could limit the chains to 3 peers or so. This way, only the device at the end of the chain is actually sending to the iPad, and the iPad is responsible for de-muxing the states of each controller. I haven't tried it, so I have no idea if it will actually work.
Lou
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden