Chocolate Doom

Janizdreg said:

When me and my friend played a game with alpha 5, I set the game to record a demo and got the demo just fine myself, but there weren't any demos created in his Chocolate Doom folder.
EDIT: Almost forgot; In addition he could press Q and nothing happened.

Only the players that specify -record will record a demo. It's just that you don't need to all record to maintain game sync.

We did try that briefly too, and the result was the same; I got a demo, he didn't. Of course it could be that he quitted the game via the menus, if that prevents Chocolate Doom from saving the demo.

Janizdreg said:

When me and my friend played a game with alpha 5, I set the game to record a demo and got the demo just fine myself, but there weren't any demos created in his Chocolate Doom folder.
EDIT: Almost forgot; In addition he could press Q and nothing happened.

Expected behaviour, I guess.

fraggle said:

The latest sourcecode is always available from the Subversion repository, but there is also a .tar archive of the latest alpha available here.

Where is the netcode hacking going on, in the trunk?

fraggle said:
Only the players that specify -record will record a demo. It's just that you don't need to all record to maintain game sync.

Is it forcing short tics on non-recorders? (I think this was mentioned before, but I couldn't find it on the thread.)

RazTK said:

Expected behaviour, I guess.

Actually, the original game did indeed record demos if you exited via the menu. I and someone else have brought up this issue and fraggle is aware of it. Whether he's done something about it yet, I'm not sure.

I presume RazTK meant that you wouldn't expect a demo to be recorded for a player who didn't include -record in his command line, nor for Q to work for him.

Grazza said:

I presume RazTK meant that you wouldn't expect a demo to be recorded for a player who didn't include -record in his command line, nor for Q to work for him.

Exactly.

If one player isnt recording he is in long tics mode ... then the recording guy get a long tics demo. Unless recording on one side switches the non recording player to short tics ?

VinceDSS said:

If one player isnt recording he is in long tics mode ... then the recording guy get a long tics demo. Unless recording on one side switches the non recording player to short tics ?

I think so.

fixed :)

myk said:

Is it forcing short tics on non-recorders? (I think this was mentioned before, but I couldn't find it on the thread.)

Yes.

Here's the logic:

If any player is recording a non-longtics demo (ie. Vanilla demo), the game gets forced to shorttics for everyone.

If you are recording a longtics demo then the game is not forced to shorttics.

In Vanilla Doom, if you were recording a demo in a netgame, all players had to be recording. This is because when you record a demo, the internal 16-bit (longtics) turning value is squashed down to an 8-bit (shorttics) turning value before being written to disk. If one player did this and not the rest, the game would go out of sync (essentially because on the recording player's system, all the players were turning by a slightly different amount to on the other players' systems).

If one player is recording a Vanilla demo, all players get sent a message informing them that this is the case (to warn about the decreased turning resolution). It would also be possible to modify a server so that, instead of allowing players to force the game into shorttics mode, it would reject connections from players wanting to decrease the turning resolution to record demos.

fraggle said:
Yes.

That kills Doom's "don't record behind my back" feature, because normally both have to agree to record, or the game will fail. But I guess that if the message the players get is clear enough, that's fine. Is it an ingame message like for turbo, or an initial startup message?

Another thing I noticed; an additional -longtics parameter clutters the command line, so why not an alternate -record command instead? It could be something like -ltdemo (same length as -record, for easy replacement by overwriting). Thus you'd use either one or the other, not two switches every time you want to record a long tics demo. You don't need an additional -playdemo because the engine automatically detects and reads "v1.91" demos, although it would be better if Chocolate warned you the recording uses long tics.

I like this Chocolate Doom thing--even though I never played .EXE. It's neat to feel how they sorta played it! Two things I'd like to see are options for higher resolutions (easier on the eyes), and the ability to reassign the weapon keys.

Use PrBoom then :P

Hmm, so with the way the sync works chocolate-doom seems unplayable if one person pings 168 (like my friend). Like it tries to equalize the lag or something? On a chocolate-doom server that behavior makes the game unplayable for both me and my friend. But if I run a zdaemon server, the game runs better for both of us--even though he still pings at 168. Someone in the IRC chat told me it was because chocolate-doom doesn't have asynchronized netcode or whatever. Could there be an option put in for that? I guess the synchronized code is supposed to make it more fair, But not much can be said about fairness if both players can't play right at all anyway.

I haven't tried playing anyone on a dedicated Us server (there don't seem to be any) yet. Haven't tried playing against someone closer to me either (my friend is west coast, and I'm east coast). At what ping does the game become playable?

Draxamus said:
Could there be an option put in for that?

Chocolate Doom's stated purpose it to port Doom as closely as possible, and Doom uses synchronized connectivity (each client must wait for the others for every action), so that seems out of place. Though it might make a good Chocolate Doom mod, maybe adding a few features that go beyond a standard Doom port (8 players, team scores, CTF, player names ingame, etc.) That said I've tried it only with low pings in local urban games, and it seemed pretty good; reports from people trying it over longer distances seemed to indicate that currently the connectivity is not as solid as Doom's, so that perhaps the performance can be improved.

Don't see why bad connectivity should be preserved--it'd still feel like DOOM2 running with better connectivity--except it'd feel like it was running better. Certainly a switch for it in case people still want everything in sync (although it still seemed as though things weren't exactly in sync for each player). Besides, isn't the default to not have the exact same system as doom2 for connections (no indigo lag)? That already shows an interest in similar changes--or options.

Draxamus said:
(although it still seemed as though things weren't exactly in sync for each player).

Even with lower ping what asynchronous models do is that they don't show the client their exact position; instead trying to balance things out so that you don't feel any slowness, but you're never in the right place unless the ping is very close to 0. It's not better, it's just more appropriate for more populous MultiPlayer specific engines, and for higher pings, where it will still play badly; it just does not feel as bad, but stuff is less predictable or consistent because it's misplaced.

It's also possible that currently ZDaemon's code might be more efficient than Chocolate Doom's, but that's not related so much to the synching method (as I mentioned above, Doom, also synchronized, is apparently smoother than Chocolate Doom, overall).

Draxamus said:

Hmm, so with the way the sync works chocolate-doom seems unplayable if one person pings 168 (like my friend). Like it tries to equalize the lag or something? On a chocolate-doom server that behavior makes the game unplayable for both me and my friend. But if I run a zdaemon server, the game runs better for both of us--even though he still pings at 168. Someone in the IRC chat told me it was because chocolate-doom doesn't have asynchronized netcode or whatever. Could there be an option put in for that? I guess the synchronized code is supposed to make it more fair, But not much can be said about fairness if both players can't play right at all anyway.

I haven't tried playing anyone on a dedicated Us server (there don't seem to be any) yet. Haven't tried playing against someone closer to me either (my friend is west coast, and I'm east coast). At what ping does the game become playable?

I'm not sure I understand the point you're making entirely. ZDaemon has client-side prediction which hides the lag you experience, meaning that if you press a key to move, you will appear to move immediately, even though you have not actually received the confirmation back from the server. Effectively, it gives the illusion of having no lag. Is this what you mean? Chocolate Doom does not have client-side prediction.

myk said:

Doom, also synchronized, is apparently smoother than Chocolate Doom, overall).

I'd certainly like to know more about this if this is the case, because I haven't yet been given any such reports.

fraggle said:
I'd certainly like to know more about this if this is the case, because I haven't yet been given any such reports.

It was DevastatioN who said he tried playing with a higher ping. I guess he thinks programs get debugged magically, because I told him to send you a report. He said something like he'd get you on IRC, although we talked more about the mouse support then. Aslo try asking Vince (PerOxyd); I think he said something similar. I'd give more info but my ping is either very low (sub 50) or very high (over 200).

fraggle said:

I'm not sure I understand the point you're making entirely. ZDaemon has client-side prediction which hides the lag you experience, meaning that if you press a key to move, you will appear to move immediately, even though you have not actually received the confirmation back from the server. Effectively, it gives the illusion of having no lag. Is this what you mean? Chocolate Doom does not have client-side prediction.

That could be what I mean! People are telling me different things. But what you said sounds like what I mean. It's much more difficult to play when you move and have to wait a few seconds to see it happen, rather than how zdaemon does it.

Draxamus said:
It's much more difficult to play when you move and have to wait a few seconds to see it happen, rather than how zdaemon does it.

It only does that if the ping is high, with a low ping (under 100 or so if the code is working fine) a synchronized connection is both fast and exactingly precise. What needs to be examined here is efficiency, not synchronecity.

If you have to wait a few seconds, then there's high a ping and possibly packet loss. How far away was your opponent?

I was running the server, and his ping to me was 168. He's on the west coast; I'm on the east coast (US). It's high, but it shouldn't be entirely unplayable on map01. On zdaemon that is still playable on map01.

Also if games are only playable under 100, this makes playing with someone overseas pretty impossible.

Maybe efficiency plays into it too, but Fraggle himself just said part of it has to do with client-side prediction. He described my problem exactly.

Draxamus said:
Maybe efficiency plays into it too, but Fraggle himself just said part of it has to do with client-side prediction. He described my problem exactly.

I described your ping lag as well; what matters here is making it a smooth as possible, not breaking the interclient synch in order to provide an illusory smoothness for each player. Any smoothness has to be real, and the idea is to get local or semilocal games working well, not international or overseas games. That's the prerogative of engines like ZDaemon, or a mod of Chocolate Doom specifically made to provide public servers, which sacrifice precision for the higher potential lag required in public games or games with many players (more than four).

Feedback with a ping of 168 should be quite valuable and I bet the performance can be improved, but don't expect total smoothness because that's only possible if you're closer or if the Internet somehow speeds up through an improved infrasrtucture (either meaning lower ping).

168 isn't ENTIRELY smooth on zdaemon, but it doesn't throw your game all the way off because of the client-side prediction. To euro servers I usually ping about 140-150 though, and as Chocolate-Doom handles lag now it still seems like even that'd be a problem. There aren't many people to play just locally. Maybe in CZ there are, but in the US there's only a few people. Most of the map01 competition is overseas, and what's wrong with wanting to play a more authentic map01 game with those people?

Also why isn't the goal of Chocolate-Doom to make internet games run better for people? I mean isn't that the reason it has netcode in the first place?

It doesn't have to be a sacrifice. It could just be made an option. In lower ping games you could play without the client-side prediction or whatever, and in higher ping games you could opt to use it. Just make a switch for something like that.

Draxamus said:
Also why isn't the goal of Chocolate-Doom to make internet games run better for people?

No, the goal is to port Doom; due to some reports, it appears that Chocolate Doom's network code isn't currently as solid as Doom's is over Kahn, Kali or GIT, though that has to be examined and tested.

I mean isn't that the reason it has netcode in the first place?

It has netcode just like Doom has had netcode all along; I doubt fraggle is thinking about adding a type of networking that's in no way supported by Doom itself.

Draxamus said:

It doesn't have to be a sacrifice. It could just be made an option. In lower ping games you could play without the client-side prediction or whatever, and in higher ping games you could opt to use it. Just make a switch for something like that.

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

myk said:

No, the goal is to port Doom; due to some reports, it appears that Chocolate Doom's network code isn't currently as solid as Doom's is over Kahn, Kali or GIT, though that has to be examined and tested.

It has netcode just like Doom has had netcode all along; I doubt fraggle is thinking about adding a type of networking that's in no way supported by Doom itself.

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?

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.

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.

Jon said:

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

Well, I mean I figured Fraggle was doing his netalpha version of chocolate-doom because he was interested in getting some proper internet games going.