Thank you very much for your response, and may I point out some details:
>> It works synchronously, but somehow, when I play in client window,
>> both client and server have 17 fps, while when playing in server
>> window, server has 44 fps while client has 5, and due to forced
>> synchronization, they both run very slowly (I wonder how come server
>> says it has 44fps?).
>>
DLB> Well, for a 2 player game of this sort, I'd think there should
DLB> be one server and TWO clients... It sounds more like you have a
DLB> master-slave arrangement with the slave forced to synchronize to the
DLB> master.
Yes, that's what I have. I was already told I should have 1 server and
2 clients, well I will, but I'd really like to make it work the
master-slave way now.
DLB> If you are running on Windows,
Yes, I am
To answer the rest of your message: the "client" and "server" (C and S
below) are actually equal in my implementation. They both compute
everything. I was told it's not smart to do that, but I can't see why
is it better to have server compute everything: there are only 2
players, and there's quite not much computations, while transferring
current status is much more traffic-consuming than simply transferring
user motions.
Below I outline what S and C do:
S:
loop
draw screen
accept player1 input from mouse/kbd
send player1 input to C
process player1 input
hang till C sends us player2 input
process player2 input
do the nasty computations :)
end loop
C:
loop
draw screen
hang till S sends us player1 input
process player1 input
accept player2 input from mouse/kbd
send player2 input to S
process player2 input
do the nasty computations :)
end loop
So you see C and S should cause equal load of CPU.
By the way, yesterday a friend of mine kindly agreed to test the game
online with me, and my God I was so happy to see it DID connected and
we could play (yes, this is the first program in my 10+ years of
programming that sends something over the web), but the speed is
overwhelmingly dreadful, near 3 fps :), while my 1.2 Celeron said I
had 21 fps, and his 3.0 Pentium said he had 120.
He tends to think that my problem is that they both hang to wait for
the input of each other, and that happens after each frame is drawn.
Well, it is lame, but why does it work fine at my pc when client
window is active?
And another important note - he also tested 2 instances playing via
localhost at his PC, and they both indeed had 35 fps, no matter which
window was active. I believe he has hyperthreading turned on while I
don't, but I wonder home come it wouldn't work without it? I've looked
at my CPU load, and for C being active we have 45% for C/45% for S,
while for S being active - 88% for S/ 11% for C :((
I'd really welcome any suggestions, please.
DLB> the program with the input focus is probably running at a higher
DLB> priority... So the "server", when having input focus, gets to compute
DLB> lots of stuff while the client gets less CPU time... and if the
DLB> client then (whenever it does a frame say) does a transaction with
DLB> the server, it may do nothing while waiting for the
DLB> server to respond.
DLB> When the "client" has the focus, the server may be processing at
DLB> lower priority, and the two only seem to match speed because the client
DLB> is blocked waiting for a response from the server (allowing the server
DLB> to run at full speed until it sends the response).
>> Does anybody have an idea how can this be? Not that users will test 2
>> game intances communicating via localhost, but I need to make it work
>> properly.
DLB> Define "work properly"... It sounds like they are working
DLB> properly /as coded/ and are being affected by OS priority schemes. I
DLB> say "as coded" since, as I mentioned in the first paragraph, it sounds
DLB> like you have your server doing double duty -- both as a client and as
DLB> the server for the second client. The server should not have ANY client
DLB> type interface (other than start-up and shut-down or debug override
DLB> commands). All frame-based rendering should be in the clients. I also
DLB> suspect that, with two clients and a server, you'd see the same behavior
DLB> -- the "non-input" client will be running at a lower priority, thereby
DLB> achieving a lower frame-rate.
DLB> It also sounds like your server is doing something like:
DLB> loop
DLB> if socket has data then
DLB> read socket
DLB> compute new state
DLB> send reply
DLB> end if
DLB> do nasty computation
DLB> end loop
DLB> This logic will suck up as much CPU time as the OS will give the
DLB> program... While if the client looks like
DLB> loop
DLB> send data to server
DLB> read reply (blocking)
DLB> do nasty computation
DLB> end loop
DLB> then it not only has to compete for CPU time, it does nothing while
DLB> waiting for the server to handle the section inside the IF block.
DLB> But what would happen if you put something like os.sleep(0.025)
DLB> inside the loops? Assuming the loop takes 0.025sec to process, the total
DLB> comes to 0.05 seconds (20fps) AND releases the CPU for the other process
DLB> to compute.
DLB> --
DLB> > ============================================================== <
DLB> > [EMAIL PROTECTED] | Wulfraed Dennis Lee Bieber KD6MOG <
DLB> > [EMAIL PROTECTED] | Bestiaria Support Staff <
DLB> > ============================================================== <
DLB> > Home Page: <http://www.dm.net/~wulfraed/> <
DLB> > Overflow Page: <http://wlfraed.home.netcom.com/> <
--
Best Regards,
Michael Rybak mailto:[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
