Skip to main content
GameDev.net gamedev.net
🔒 Locked

Program slow down after network code added, help?

Started by leggyguy Dec 6, 2001 at 12:03 PM 7 replies 450+ views
Original Post
leggyguy
leggyguy
hi, I have added some DirectPlay networking code to my program. Basically the exact same code used in the simple peer program supplied with the DX8 SDK. The program worked great before the network code was added, but once the directplay code was added, the program has started performing very slowly. The frame rate is about the same as it was before, but all the input to the program is slow. It takes a quarter second from the actual mouse moving to the mouse moving on screen, (same with keyboard input; output to screen (chat) is a quarter second after the button press). The direct input code is my own, and the mouse draws and erases itself each frame. However, the input was working perfectly fine before I added the DP code. So I am fairly sure it is the dp code slowing the program down. I am fairly new to DP coding, although I have worked with DX quite a lot over the last year or so, and generally have no problem with it. But I have no idea why the program is so slow now. Can anyone help with some suggestions as to what may be causing the problem? I know you can''t see the code, so I am really looking for typical problems that I can then check for in my code. I really appreciate any help, so thanks in advance for any replies.
anjee
anjee
How many messages (packets) are you sending/receiving. If none, how are you using directplay, event based or by polling (Don''t beleive that''s possible anymore, though)

leggyguy
leggyguy
I am sending messages only when the player plays a move (it is a turn based strategy game, a player may play a move perhaps every 20 seconds, but that would be a fairly quick player. Certainly I am not sending more than a message every 20 seconds after the initial startup phase, when a message is sent every frame, nearly. However, this startup phase is going smoothly, the input slowdown occurs when no messages are being sent.)

When we do receive a message, we would receive one of 8 different message types. When we receive a message we receive a struct with 7 ints in it. Our callback handling the messages then passes a pointer to this struct to the part of our main game code which handles it. In the callback, we have a switch call which looks at the type of message (identified by one of the int) and then decides which main game function to pass the pointer to the received struct.

I am using DP event based.

a person
a person
every 20 SECONDS?! i think you meant 20 times a second which sound more reasonable. look into interpolation. btw mouse movement should be locally handled, and sent to the server with the updates that occer 20 times a second.
leggyguy
leggyguy
Well, as I say, I am new to DP, and new to network programming altogether. I am using a peer-to-peer session, and the SDK docs seem to indicate that a message is only sent from one computer to another if and when a player does something which my code thinks their opponent should know about. But I may be very wrong.

Actually, when I take another look at the program with a fps readout switched on, I actually am running, sometimes, at a low fps, perhaps as low as 10 per second, down from the usual 30 it was running on smoothly before the dp code was added. HAving said that, sometimes it runs at a nice 30 fps (nice on my naff g card that is) as it was before. I am puzzled, but will plough through my code and see what I can see.

Edited by - Leggyguy on December 6, 2001 3:39:04 PM
anjee
anjee
Just a quick question... Are you using DrawText or CopyRects() anywhere in your program? If yes...get rid of it. You''ll see your FPS atleast double..

But I wouldn''t know why your app slows down that much though..
I still run on 180fps, with ~7packets/sec (up), and lots more down
leggyguy
leggyguy
Well, I just removed about 80% of my message handling callback, and the fps is right back at its best again. So obviously, I am handling incoming messages poorly.

Being new to this, I suspect I am doing something wrong in the callback when I receive a DPN_MSGID_RECEIVE message. I am doing everything the obvious way for a beginer, which means not forming a queue of the incomming messages, which perhaps is where I am going wrong, but with my code only sending messages when a player presses a button (I think) which is only 3 or 4 times per minute, I never would have thought the program building up a backlog of unsorted messages would be a problem.


Edited by - Leggyguy on December 7, 2001 5:55:19 AM
anjee
anjee
I just process messages directly, the moment the Receive event is fired. No problems at all (Using VB though )

btw, you aren''t starting the game *from* an DP event? If you do, the program will be execute in a new DP thread, making things uncontrollable...

Also, I was just messing around with the DP8.1 network simulator control... you haven''t turned that one with a high ping? (It''s off by default, so you probably haven''t it on), it''s in the sdk\utilities directory.

And finally, are you sending packets using "sync" ... making your program wait for every message to be sent?

--

leggyguy
leggyguy
I seem to have got rid of much of the slowing down. Now the program runs fairly smoothly, at a neet 30 fps (yep, that is pretty damned as good as my card will let it run ).

After a little while, though, what happens is something like a frame stick. It will be going along nicely at 30 fps, only for one frame to stick and stay onscreen for perhaps a quarter second. I am not moving the mouse or pressing keys which means my program is doing absolutely nothing except drawing (blitting and flipping in DDraw) and handling incoming messages (which as I said are fairly few and far between).

The code is fairly messy right now, with plenty of globals, so I will encapsulate it and see if tidying it up makes it run any better. But the general speed is much improved, so at least I can continue to work on it. When it is close to finished, I will look again at the DP code and see about speeding it up.

Thanks for your replies.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.