Draxamus said:
Split hairs more. I was saying solid internet gameplay should be A goal. Porting Doom would be the main goal, but what's so great about that if you can't enjoy the classic doom gameplay with other players?

You can, as long as you have buddies relatively close; "classic Doom gameplay" includes among other things synchronized networking.

I thought the networking protocol used by chocolate-doom now WASN'T supported by doom2 at all, because doom2 used a protocol that is obsolete now.

The sound code in Chocolate Doom is written from scratch too, but like the netcode it tries to do what the game itself does in its raw form. The functionality is the main concern; underlying processes might change a bit if porting requires that.

You look at chocolate-doom networked games and you see that -oldsync is a switch now too. I don't see the harm in adding a switch for client-side prediction if it helps with higher pinged games--especially if such games are unplayable otherwise. I don't know why anyone would be against something like that.

The -oldsynch was added for purism after the code had been written without Indigo lag.

Personally I'm all for (Chocolate) Doom-based C/S; but like Jon suggests, that needs its own project, perhaps adding additional features that fit in with popular online play (CTF, teamplay, names, scoreboard, ingame joining, spectating, cheat-proofing, map cycling, etc.), and that are sometimes necessary for it. It's already enough of a task, among other things, to debug the purist-styled network code, which is the one that can provide the precise games Doom is know for, without adding asynchronous networking.

If you live in a place that doesn't have other players close by, use ZDaemon; at least it has classic play that some people put effort into, as well as the type of net code you need for such long distance games.

Share this post


Link to post

It would be cool to have a proper TCP/IP doom, but perhaps thats a task for another project?

There already are several TCP/IP DOOM source ports, some of which are client/server too (ZDaemon, Doomsday plus more).

Share this post


Link to post

DaniJ said:
There already are several TCP/IP DOOM source ports, some of which are client/server too (ZDaemon, Doomsday plus more).

So is Chocolate Doom, but he means a completely classic thing (thus the "proper") otherwise like ZDaemon where you run servers, you have a list of them all, and people can join from all over the world. And that necessarily requires asynchronous networking.

Share this post


Link to post

Yeah, I know myk but I'm somewhat confused as to what Draxamus is suggesting.

From what I understand he is asking for synchronized networking AND client-side prediction within a client/server model...

Really Draxamus, your best bet is to simply use irc or something to arrange games to play in Chocolate.

Share this post


Link to post

DaniJ said:
Yeah, I know myk but I'm somewhat confused as to what Draxamus is suggesting.

From what I see it seems to me his request is to a good degree affected by his current circumstance where his playing buddy is kind of far away (ping 168) and wants as classic a game as possible from there.

But yeah, either finding opponents that are closer by or sticking to ZDaemon with all classic settings enabled would be the best choices currently.

Share this post


Link to post

I also get the click (or pop) sound at the end of every sound effect on my Win98se machine, not nearly as bad as above, but it's the same noise. This has been my only issue and I love the port!

Share this post


Link to post

I just noticed that the clicking stops after about a minute, and that chocolate doom seg faults when exiting (only when playing a demo) right before it displays the red quit screen.

Share this post


Link to post

exp(x) said:
I just noticed that the clicking stops after about a minute, and that chocolate doom seg faults when exiting (only when playing a demo) right before it displays the red quit screen.

Do you know if that happens with PrBoom or Eternity? (They all use SDL.)

Share this post


Link to post

My older port, SMMU, actually had client-side prediction within a syncronous client-server based system of the kind that Chocolate Doom has, so it is possible. I'm kind of loathe to add it though, because it is a major change to the game behavior and I want to stay as close as possible to the Vanilla multiplayer behavior.

I am kind of surprised that a ping of 168 is so unbearable, because I've played with Bloodshedder using the Chocolate Doom multiplayer, and that's a cross-atlantic game. One obvious question: have you disabled all peer to peer software on both ends? You should make sure you aren't downloading anything at the same time or using your Internet connection for anything else.

Share this post


Link to post
exp(x) said:

I have a problem with sound when playing demos using chocolate doom. There is a constant clicking noise that isn't present when launching normally and starting a game. Here is a capture so you know exactly what I mean:

http://brandon.conglacia.com/files/chocolate.ogg

That is quite nasty. Thanks for the sound file. It's hard for me to debug this kind of situation, because I expect it depends on your exact hardware setup. I'll have a look through the sound code and see if anything isn't quite right.

Share this post


Link to post
fraggle said:

My older port, SMMU, actually had client-side prediction within a syncronous client-server based system of the kind that Chocolate Doom has, so it is possible. I'm kind of loathe to add it though, because it is a major change to the game behavior and I want to stay as close as possible to the Vanilla multiplayer behavior.

I am kind of surprised that a ping of 168 is so unbearable, because I've played with Bloodshedder using the Chocolate Doom multiplayer, and that's a cross-atlantic game. One obvious question: have you disabled all peer to peer software on both ends? You should make sure you aren't downloading anything at the same time or using your Internet connection for anything else.


I know both of us didn't have any other downloads going. I don't know what you consider bearable--but on a map like map01 my brain expects my actions to be in time with what's happening on the screen. At that ping I would start moving ahead every time. I would move--then I would expect to be moved so I'd move again, before my first move ever finished being completed. Can't play map01 like that.

Did the creators of .EXE prepare for games taking place between people with that sort of distance? I'm assuming no, so why not adopt new features to accomodate that sort of thing? If you add it is as just an option people could still play the usual way at better pings.

Share this post


Link to post

fraggle said:
I am kind of surprised that a ping of 168 is so unbearable, because I've played with Bloodshedder using the Chocolate Doom multiplayer, and that's a cross-atlantic game.

I'd say your ping to Bloodshedder should have been lower, since connectivity between eastern US and England is pretty good; maybe 110 or 120. Cental Europe pings 150 to the east coast, as far as I know. What really matters is that the behavior isn't worse than Doom's over an IPX tunnel, though. I'm going to urge some people in testworthy locations to provide more exacting comparisons, since their comments on the performance have been rather half-assed till now.

Share this post


Link to post

Draxamus said:
I don't know what you consider bearable--but on a map like map01 my brain expects my actions to be in time with what's happening on the screen.

The only way to do that when every action has a time loss of .168 seconds is by a "cheating" method that tells the engine to try predicting where each player is, and being somewhat wrong. Your movement might be smoother but your aim is off and you aren't where you really are in relation to your opponent.

Did the creators of .EXE prepare for games taking place between people with that sort of distance? I'm assuming no, so why not adopt new features to accomodate that sort of thing?

Asking to modify the behavior of a purist classic engine just because your favorite playing buddy is in a country on another continent does not make any sense. Just look for someone that's closer by; if you were using Doom2 on Windows 98 it'd be understandable if you couldn't find any players, but you're using an engine any person can install on a modern system. Among other reasons, it was made so that people would stop complaining about not being able to play Doom2 (including online with anyone) due to system incompatibilities, not to add new features or ways of playing it.

Share this post


Link to post
myk said:

The only way to do that when every action has a time loss of .168 seconds is by a "cheating" method that tells the engine to try predicting where each player is, and being somewhat wrong. Your movement might be smoother but your aim is off and you aren't where you really are in relation to your opponent.

Asking to modify the behavior of a purist classic engine just because your favorite playing buddy is in a country on another continent does not make any sense. Just look for someone that's closer by; if you were using Doom2 on Windows 98 it'd be understandable if you couldn't find any players, but you're using an engine any person can install on a modern system. Among other reasons, it was made so that people would stop complaining about not being able to play Doom2 (including online with anyone) due to system incompatibilities, not to add new features or ways of playing it.


The illusion of smooth movement is better than the way it is now. ZDAEMON does it that way--and even when I had to use a dial-up connection (Note: before anyone assumes, I DID NOT try to get a working server on dial-up. The server I ran was off my DSL connection) for a week, and I pinged 180--I could still perform not that bad on map01. Despite the aim in reality being off, I was still able to aim reasonably well, because I wasn't being thrown off by the lag.

And I'm not just wanting a new feature so I can play my one friend. I would think lots of people would be interested in playing people at a distance--I know I would like to play a number of euro players. If it was meant for people to play anyone online, it's not really doing that. Only letting you play local players.

Share this post


Link to post

Draxamus said:
The server I ran was off my DSL connection) for a week, and I pinged 180--I could still perform not that bad on map01.

This doesn't make any sense. You ran the server? If you run a server your ping is close to 0, unless there's something wrong with your network, or you lauched it on a server on another country. You should run the server from your computer, not from the Czech Republic.

Anyway, if you want to play over long distances, you can use ZDaemon, or get someone to start a Chocolate Doom based C/S offshoot. Unless, that is, you can get fraggle to work on the two projects in a parallel manner. That would evidently slow down his Chocolate Doom specific development and updates, though.

If someone started a C/S variant of Chocolate Doom, it would be great if they added all the features required for online play, not just asynchronous connectivity, which is kind of pointless all by itself on the basic Doom engine. If you're a coder, Draxamus, you could start it yourself, today, even.

Share this post


Link to post
myk said:

Do you know if that happens with PrBoom or Eternity? (They all use SDL.)

It doesn't happen with PrBoom.

fraggle said:

That is quite nasty. Thanks for the sound file. It's hard for me to debug this kind of situation, because I expect it depends on your exact hardware setup. I'll have a look through the sound code and see if anything isn't quite right.

I re-uploaded a longer recording. Notice how it gets milder at the start of map02 and then altogether disappears.

Edit: I forgot to re-post the URL http://brandon.conglacia.com/files/chocolate.ogg

Share this post


Link to post
myk said:

This doesn't make any sense. You ran the server? If you run a server your ping is close to 0, unless there's something wrong with your network, or you lauched it on a server on another country. You should run the server from your computer, not from the Czech Republic.

Anyway, if you want to play over long distances, you can use ZDaemon, or get someone to start a Chocolate Doom based C/S offshoot. Unless, that is, you can get fraggle to work on the two projects in a parallel manner. That would evidently slow down his Chocolate Doom specific development and updates, though.

If someone started a C/S variant of Chocolate Doom, it would be great if they added all the features required for online play, not just asynchronous connectivity, which is kind of pointless all by itself on the basic Doom engine. If you're a coder, Draxamus, you could start it yourself, today, even.


You're pushing my parathetical comment into something else. I was saying that for a week I pinged 180 to zdaemon servers because of my dial-up connection. And I was trying to make the point that because of the way zdaemon handles lag, I as still able to aim without being distracted--and thus had a playable game. The statement in parenthesis was supposed to DETER CONFUSION, as I anticipated someone might read it and think I tried to run my chocolate-doom server off dial-up.

I can play zdaemon with people at a distance, but the point is I'd like to try some classic feeling games with people at a distance. That's why I'm suggesting that Fraggle incorporate things for better functionality over long distances.

Share this post


Link to post

Draxamus said:
I can play zdaemon with people at a distance, but the point is I'd like to try some classic feeling games with people at a distance.

What, so you're saying X-Doom servers with all the classic settings on don't have a classic feeling? You must have years and years of exclusive Doom2 experience over DWANGO, LANs, and IPX tunnels if you're affected by the very slight differences between Chocolate Doom and ZDaemon + X-Doom features in such a way as to argue this into a project like Chocolate Doom to this extent.

Now get your coding skills cracking with that C/S chocolate offshoot; I'd like to see some progress! The source is always available.

Share this post


Link to post

There seems to be a couple of bugs in alpha 5 related to loading saved games:

Loading a game using the -loadgame command line parameter seems to be buggy (the player is rotated roughly 180 degrees plus I think the game also fast forwards the saved situation a bit).

Certain saved games that work in vanilla crash Chocolate Doom. Here's one (which might be related to lots of projectiles flying in the air).

There's also a problem with loading saved games where there are Revenant fireballs flying in the air. If the game remembers to add trails to the fireballs in Chocolate, they start homing on a point in the map. This doesn't happen in vanilla (even though vanilla sometimes does add the trails, but there's still no homing). Here's a WAD and a saved game if you want to test this for yourself.

And finally, Chocolate and vanilla differ from each other when loading an incorrect saved game which was saved when playing with a different PWAD. Chocolate just crashes, whereas vanilla actually loads the game (even though everything is messed up).

EDIT: Not save game related, but Chocolate Doom plays music and sound effects even though I've set snd_musicdevice and snd_sfxdevice to 0 in the Doom configuration file.

Share this post


Link to post
myk said:

The only way to do that when every action has a time loss of .168 seconds is by a "cheating" method that tells the engine to try predicting where each player is, and being somewhat wrong. Your movement might be smoother but your aim is off and you aren't where you really are in relation to your opponent.

Actually, that's wrong. In a game using client-side prediction, if your position is correctly predicted, your position when you press "fire" is where you will fire from.

Consider this example. Suppose you are at position (100, 100). Then you might experience the following:

1. You press fire
2. You sidestep to the right, bringing you to position (150, 100)
3. Your rocket launcher fires, but the rocket originates from (100, 100), your previous position 50 units to your left.

The rocket fires from the position you were when you pressed fire, so aiming itself is accurate. The problem is that it can be disorienting to be firing from a different position from where you appear to be.

Essentially, the game is still lagged exactly the same as before. Lag means that there is a delay between the sampling of your controls and the effect they have on the game world. This always exists whether you use client-side prediction or not. What it does is remove the lag on your view of the world, so that when you fire, you will see things from the position you will be when you *actually* fire.

Share this post


Link to post

fraggle said:
Actually, that's wrong. In a game using client-side prediction, if your position is correctly predicted, your position when you press "fire" is where you will fire from.

In the map, yes, otherwise you would crash into walls. Don't some models use some sort of "correction" (optimally on other things, not you) to attempt to give you time to react? Where's the "prediction" of all it is is a delay? Prediction means being able to tell before it happens.

But with asynchronous lag you can only guess where your opponent really is. Some people can get some idea according to the current lag out of experience, but if you add the opponent's movement in different directions to the deal, it becomes pretty unmanageable quickly.

Share this post


Link to post
myk said:

In the map, yes, otherwise you would crash into walls. Don't some models use some sort of "correction" (optimally on other things, not you) to attempt to give you time to react? Where's the "prediction" of all it is is a delay? Prediction means being able to tell before it happens.

In a predicted game, your apparent position when you press "fire" is where you fire from. That is not the case in a game without prediction.

But with asynchronous lag you can only guess where your opponent really is. Some people can get some idea according to the current lag out of experience, but if you add the opponent's movement in different directions to the deal, it becomes pretty unmanageable quickly.

I'm not sure what you mean by "asynchronous lag". Lag exists regardless of whether you're playing in a synchronous or asynchronous multiplayer engine.

In a synchronous system, all players must exchange movement commands for each tic. There is a delay between the generation of the movement commands (via sampling of keyboard/mouse inputs), and the game advancing (once inputs from all other players have been received). Lag exists because of this.

In an asynchronous (event-based) system (like Quake/ZDaemon), a client sends a movement request to a server, which must then send an position update back to the client. The lag exists because of the network round trip time to do this.

In both cases, there is a delay between your input and the effects of that input. That is true in Doom and Quake-like systems, and the effect is exactly the same. The problem of aiming at lagged players is exactly the same as well, because the lag means that players will be at different positions from the time at which you press fire to the time at which you actually fire.

What client-side prediction does is move your player's view immediately, effectively bypassing the lag by not waiting. So, *your* position that you see when you press fire is the position that you actually fire from. This isn't true in a system without client-side prediction.

Share this post


Link to post

fraggle said:
In a predicted game, your apparent position when you press "fire" is where you fire from. That is not the case in a game without prediction.

I had written a longer reply here but I just read something; that it's "prediction" since it'll give the user info before getting it from the server... that sometimes causes weird effects, like something pushing you off when you had apparently move through an area, and stuff like that. Or being dead and firing a shot that never even came out according to the server.

I wonder, are hybrid methods used, or possible?

By the way, by "asynchronous lag" I meant the lag phenomenon as it is experienced over an asynchronous model, since lag is used to refer to an effect ingame "hey, man, it's laggy", when not defining it as a value in relation to the time it takes for info to get through, as opposed to the "slow down" lag in the other model.

Share this post


Link to post
myk said:

"slow down" lag in the other model.

Careful you don't get confused here; Doom only slows down when high lag is experienced because of the flawed way that the player sync code works; it has no relation to the actual synchronous multiplayer architecture.

Share this post


Link to post

fraggle said:
Careful you don't get confused here; Doom only slows down when high lag is experienced because of the flawed way that the player sync code works; it has no relation to the actual synchronous multiplayer architecture.

Now I'm confused; one would assume a peer/client in game depending on a synchronous multiplayer model without Doom's player synch code, and supposedly something more efficient in place, would slow down when input from the other client(s) is late, just not as readily.

Share this post


Link to post
myk said:

Now I'm confused; one would assume a peer/client in game depending on a synchronous multiplayer model without Doom's player synch code, and supposedly something more efficient in place, would slow down when input from the other client(s) is late, just not as readily.

The game will pause if input is lost, yes. Also, as tic commands are generated, they are stored in a buffer until the corresponding commands are received from other players. If that buffer fills up (because of enormous lag, packet loss or a connection problem for example), the client has to stop sending until it "catches up". If your buffer was 35 tics, for example, the game would start to slow down after 1 second (using a Doom system with 35fps).

Doom has code that attempts to make all players generate and transmit tic commands at the same time. It doesn't actually work that well; it's the reason for the indigo lag problem. Part of the problem is that it assumes that you're playing on a low latency network like a LAN. When put on the Internet it kind of falls over.

The code misinterprets high latencies (ping times) as indication that the client's clock is not properly synced with the other players. Because it thinks that it's getting "too far ahead", it slows down the clock to try to bring itself back in sync with the other players. Of course, in an Internet game all players end up doing this. The end result is that in a game with high latency players, the whole game slows down.

Share this post


Link to post
fraggle said:

I've added support for screenmultiply=2 in fullscreen and fullscreen=2 ("letterbox mode" with black borders). These let you run in 320x240 (1/2), 640x400 (2/1) and 640x480 (2/2).


Would you mind implementing a windowed 640x480? My monitor has trouble kicking into fullscreen mode for some reason (so I can't see anything for about 2 seconds), and the fullscreen 0; screenmultiply 2 window is too small.

Share this post


Link to post

It would be nice if screenmultiply accepted 3.

Share this post


Link to post
ultdoomer said:

Would you mind implementing a windowed 640x480? My monitor has trouble kicking into fullscreen mode for some reason (so I can't see anything for about 2 seconds), and the fullscreen 0; screenmultiply 2 window is too small.

640x480 mode is exactly the same as 640x400, but with black borders. Are you saying that there is just a delay before the screen appears, and that this is the problem? I could maybe add some special option that gives the screen a couple of seconds to settle after changing modes.

exp(x) said:

It would be nice if screenmultiply accepted 3.

Can do!

EDIT: Done. I really need to get a new release out already.

Share this post


Link to post
This topic is now closed to further replies.