In that case, wouldn't just typical multiplayer prediction logic be better? I don't expect that you'd get 60Hz packets neatly over the internet (you do over LAN though), but I could be wrong there.
How about letting the server send out update packets for the ball; position+velocity. The clients handle time offsets (wrt the server) and ballPos=position+t*velocity. I do that type of interpolation (prediction really) in my racegame, and it works better than expecting packets to drop in neatly every 1/60th of a second. You probably looked into this, otherwise check out Half-Life 2's multiplayer page on prediction/lag. There's a bunch of ways to either predict (HL2 really takes the last 2 packets and interpolates between those; I take the latest packet and start interpolating from there, to combat lag). The tricky part is getting a good client time offset (to calculate a servertime which is quite correct on all clients; something which can be tested by flashing the screen every second for example, quite a nice visual test). The only real events for a tennis ball are when it gets hit, which will be the main concern. But if clients predict this as a player hits the ball, you'd see virtually no lag. Ruud On Fri, May 25, 2012 at 4:51 PM, Emmanuel Rivoire <[email protected]>wrote: > At 19:55 25/05/2012, you wrote: > >> In that case it sounds like the optimization chances are more at your >> end, trying to aggregrate information. If overhead is larger than the data, >> you're probably sending too little data. ;-) >> > > Damn, I sweat my brain off to get the smallest data needed to go over the > network, and got blamed for it..! ;-) > > More seriously, I have to send 60 packets / second, coz sending only 30 > packets/s would mean to add 16.67ms of latency and that'd be bad for my > game : it's a tennis game, it's very latency dependant ; for example, the > ball can travel almost 1 meter during 16.67ms on the start of the service. > I did a lot of things to fight back the latency at the game level and > network level, but the 1st thing is to have the smallest packet possible > sent 60 times / second, thus my concerns about all optimizations. > ______________________________**_________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/**mailman/listinfo/enet-discuss<http://lists.cubik.org/mailman/listinfo/enet-discuss> >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
