Re: the Zell solution ... it works!
Re: the Zell solution ... it works!
- Subject: Re: the Zell solution ... it works!
- From: JP May <email@hidden>
- Date: Thu, 12 May 2011 14:03:08 +0200
> 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.
Intriguing ....
> Looking at Wireshark this would usually occur on a TCP retransmit. Switching to AsyncUdpSocket actually produced a noticeable difference for us.
Huh - if so, that is a critical fact, thanks!
> 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.
intriguing ..
> 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
Fascinating!
> 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.
I've been thinking about this ..
One thing, I think it might be just too hard to program! :)
Secondly I was wondering ... it all has to go through the same WIFI hub anyway! I wonder if it would actually make much difference give that that is the case! Perhaps it's sort of a false economy? I don't know...
You know, I tend to think in terms of just "channels" of info rather than states .. for example, if there's an accelerator pedal or some other knob, that runs from 0 to 100 ... i just want that channel, that number, back at the server all the time.
_______________________________________________
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