where can i get this python stuff?<br><br>markus<br><br><div><span class="gmail_quote">On 12/14/06, <b class="gmail_sendername">Neil Toronto</b> <<a href="mailto:ntoronto@cs.byu.edu">ntoronto@cs.byu.edu</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">System: 1.66GHz Intel Core Duo laptop with frequency scaling, Intel<br>945GM graphics, Ubuntu
6.10.<br><br>On this system, with com_maxfps set to 60, Python is doing fine at low<br>latencies, and mostly fine at high.<br><br>Here's some background. I've got the Python client game loaded and<br>rendering the map, all players, all items, and some effects like rocket
<br>explosions. Most of the sounds play. A significant part of all this is<br>player prediction, which I'll go over now. It's actually rather<br>annoying, but kind of cool at the same time.<br><br>If you remember Quake before QuakeWorld, you might remember that it was
<br>impossible to play online without a really good connection. The reason<br>is that the snapshots your client got were interpolated between to get<br>your current position. The snapshots, of course, had some delay. The end
<br>result is that, when you moved, it would have to bounce your move off of<br>the server before you actually saw it. If you want to see what it's<br>like, you can make Quake 3 do this by setting cg_nopredict to 1. Things
<br>like rocket fire and bullets are still like this.<br><br>Player prediction compensated for that, and has been included since.<br>Here's the short version: for every frame rendered, the client starts<br>with a fresh player state from the snapshot and *plays back every move
<br>you've made that the server hasn't seen yet*.<br><br>Yeah, so that's rough on the CPU. Your client plays back about "ping *<br>FPS / 1000" moves. If you ping 500 and your FPS is 60, it does 30.<br>According to my profiling, the hardest part of moving a player is a
<br>trace (collision detection), and your average player move makes 3 or 4<br>calls to trace: to find the ground, to move him forward, to slide him<br>against a wall or another player, and to find the ground again. At 30<br>
moves per frame, 100 trace calls is pretty expensive.<br><br>Contrast this to the server game, which only has to make *one* move per<br>player move. The client game is definitely a sucker for punishment.<br><br>The good news is that Python is doing fine proxying all those trace
<br>calls, and that the traces themselves take half the time it takes to<br>render a frame when you ping 500. Python does get choppy before a native<br>DLL does, but at normal pings (sub-200) and normal frame rates<br>(sub-120), it'll perform just fine on current hardware. Also, I now have
<br>no worries whatsoever about Python's performance on either the client or<br>the server.<br><br>Couple of tidbits:<br><br>1) I've implemented cg_latentSnaps (from Unlagged), and it was way<br>easier than in 1.27. Somebody seriously cleaned up cg_snapshot.c. This
<br>cvar allows you to simulate lag. The client game simply requests<br>snapshot number "current - cg_latentSnaps".<br><br>2) I've added com_laptop, which, if 1, causes Sys_Sleep(0) to be called<br>at the end of the (busy-wait) rendering loop. It makes Quake 3 a little
<br>more laptop-friendly, and also lets you see the *real* amount of CPU<br>Quake 3 takes on your performance meter. (Otherwise it's always 100%.)<br><br>Neither of these are in the main trunk, of course, but they ought to be
<br>considered.<br><br>Neil<br><br></blockquote></div><br>