13/09/2004-14/09/2004 @04:09:07 ^05:29:20

POSITIVE REVIEW

<fri> god <fri> i clicked strobe.php and almost died

"it was a spiritual experience and i am so glad i could share it with you"

Here are some commands, which the iptables stuff especially is more for my own reference than anyone else's

Yes my monthly flash of motivation occurred the other day when I managed to force myself to work out how to play doom over the internet. This was the first time I've played the best game ever in multiplayer and in spite of the problems it was amazing!

Problems: well firstly the network code sucks for anything with a ping time of longer than a few milliseconds. Both server and client constantly spew udp packets in blocks of 6, 3 in each direction, to keep the two, or more up to four, game engines in synchronisation. The client appears not to update the screen and game world until each 6 packet exchange has been completed. When playing with somebody else who's only on dialup this means a frame rate of an estimated 1-2 seconds per frame; rather like trying to sprint along the bottom of a swimming pool. PrBoom's network code, which uses that from SDL, seems more suited to LAN play... Incidentally it was quite startling if the remote client exited, as the server no longer had to keep it updated and the game would suddenly speed back up to a normal frame rate.

The other problems were the relatively frequent crashes which seemed to occur for a variety of reasons. For example, twice the whole thing just froze up when I radioed an overly long line. This smacks of a buffer overflow or "gratuitous security hole" if you prefer.

Another thing was that my client would quit back to X a few moments after a respawn. The error message that came out was one I am very familiar with already; in the code that draws patches (sprites, essentially) directly to the screen buffer, there is a check that the patch won't spill out of the buffer. It's fine for 320x200 but I think at other resolutions the calculation introduces rounding errors that, for example, cause the game to quit instantly if you as much as finish Doom E3M3 and try to carry on into E3M4. This check was commented out in PrBoom 2.2.3 and only seems to affect PrBoom 2.2.4. It is also tripped by something unknown a few moments after you respawn after a death in multiplayer, which makes deathmatches almost useless.

You have to run the server before your partner on the remote connection runs the client, simply because if not the remote client gets its connection refused. The windows client at least doesn't seem to be able to cope with this, and it hangs. Also I found if I didn't wait a few seconds before running my local client after the remote one had connected, I would find myself staring at a black screen until I went to a console and killed all prboom and server processes manually (which doing took the whole of X with it as well, stupid thing) There's possibly some weird race conditions going on, if so probably related to the code's inability to cope well with long ping times to one of the connected clients, and that you wouldn't see this behaviour on a LAN game. But I'm just guessing here.

Nevertheless, first few times we tried to do this, it was still amazing enough to keep at it. The furthest we got was nearly to the end of map04, but sadly what I had felt to be amazing teamwork up to that point broke down when I shot the girl in the face with a rocket launcher. She respawned and her client crashed immediately afterwards. Probably for synchronisation reasons, you can't reconnect to an in-progress game, so I was quite upset. We tried again the next day, but somehow it wasn't the same. The slowdown was too much to be bothered with; I tried several times to do the jump to be able to shoot the spot on the wall that opens the BFG secret in spark's MAP01 modification. It's easy normally, but in treacle mode there wasn't the control you need to stop yourself overstepping the platform. It just wasn't the same, and I think we've got fed up now.