Well, I've finally identified the culprit in these game pauses. Surprise, it's Win32.

I discovered that whenever I'm connected to Remote Desktop and I put my computer into sleep mode, at that moment there's about a 30 to 60 second pause during which my application will not receive ANY windows messages. Sockets are processed through the windows message queue, so those messages are among those being ignored during this period. This is why the game hangs.

As a test, I wrote a bare-bones app that tracks any long delays between windows messages and logs them. A 500 ms timer tick is activated so the message handler should be called at least once every 500 ms. When I drop my Remote Desktop connection, I get an identical pause. This proves that the issue is not specific to TWGS. It is a problem with windows message queue while a Remote Desktop connection is timing out. It's possible that it's specific to Delphi apps, since both apps are written with the same compiler, Delphi 4.

I've tried setting TWGS to run at a higher priority, but I've verified through CPU logging that there is no CPU spike during these lags. It's not that TWGS doesn't have CPU. It's that windows isn't sending it messages. In fact, I verified that a thread that was running during a lag was in fact processing and did not experience the same lag. The lag is a message lag, not a processing lag.

I can't even find any reference to something like this on the net. I have no clue how to overcome it. I do know that all players experience the same pause, so it should not give an advantage to one player over another. But I am concerned that Remote Desktop is a common way to access TWGS and these pauses are likely to be common. It's very irritating. If anyone has any experience with Win32 message processing and can suggest any way to keep those messages flowing, let me know. Otherwise, I'm going to put this issue aside and go forward with the release.

I haven't noticed it on the old ver, so it might be server specific. Have you tried duplicating this on other servers, or tried alternate clients that might handle the exit more gracefully? Sounds like if we're having problems with RDC timing out, it makes sense to quit out of RDC rather than let it time out.

I'm sure there are ways to avoid this happening, but instructing TWGS users about it is difficult. Hopefully you're right and it is something limited to this server. I don't have the ability to test with any other servers at the moment, but the test is very easy. I can recreate this pause every time a RDC is dropped. No exceptions.

If I get many reports of this issue from users, I'll have to revisit it. For now, I'm moving on.

You may want to try from the windoz resource kit (dl at microsoft) the tool called pviewer.exe it will allow you monitor the proccess and thread activity of all processes in memory. You can also tweak thier priorty.


Looking forward to the release.

Hey John,

Where I work we have computer automating test task that require the video card to render stuff. We discovered that when we close RDP, the software is unable to create views for the rendering.

Your issue might not be related, but our solution might be helpful: use another remote desktop method.

http://www.realvnc.com/

Hope this help!

What's strange about this issue is that RD isn't taking so much CPU that other apps can't run. I've verified that TWGS and TW continue to run just fine. What it does is disable windows messages for running apps. And since all sockets IO is handled through windows messages, the connections just go dead until messages start flowing again. It's very annoying. And yeah, I'm sure another remote desktop app would work fine. But I'd really like to know why RD does this. It can't be expected behavior. I wasn't able to find any reference to this behavior online.