Chocolate Doom

vesperas said:

I noticed a minor issue after setting the video_driver from "" to "directx" in chocolate-doom.cfg. Basically, every time I quit the game, the music keeps playing for a couple of seconds while I'm already on the desktop. Is this a know problem? The directx driver seems to give smoother FPS btw :)

I would tend to think that the audio driver is simply finishing the playing of what's in its buffer, placed there before Chocolate Doom exited. If so, that's not really a bug, is it?

kb1 said:

If so, that's not really a bug, is it?

Of course this is a bug. If an application tells the sound system to stop, it should stop NOW.

vesperas said:

I noticed a minor issue after setting the video_driver from "" to "directx" in chocolate-doom.cfg. Basically, every time I quit the game, the music keeps playing for a couple of seconds while I'm already on the desktop. Is this a know problem? The directx driver seems to give smoother FPS btw :)

Could not reproduce on my setup (either with or without "directx", with any sound system).

vadrig4r said:

Could not reproduce on my setup (either with or without "directx", with any sound system).

I don't know if it matters but I'm on Windows 10 x64 with all the updates. (Chocolate Doom 2.2.1)

Any plans on supporting "authoritarian" lobbies? In such lobbies, the host would either supply the link to download the necessary files or they would be downloaded from the host itself, and whatever settings the host chooses are passed to those connected in the room. User would be considered "ready" once the download finishes and ignore the unready ones in case the game is started.

This would eliminate potential checksum mismatches caused by user error and make multiplayer much easier to set up.

XCOPY said:

Any plans on supporting "authoritarian" lobbies?

lol...

XCOPY said:

Any plans on supporting "authoritarian" lobbies?

The only way that will happen is if the entirety of Chocolate Doom is converted to DSL, goes closed source, and *shot*.

XCOPY said:

Any plans on supporting "authoritarian" lobbies?

Well, it is a "conservative" source port after all...

Serious answer: I've considered it in the past but it's nowhere near the top of my list of features to add. There are a whole bunch of features I'd like to add to the networking which are currently missing - the ability to rearrange ordering of players is a really basic one, for example.

Chocolate Doom's servers are basically packet forwarding servers, so "authoritarian" servers like this would be a significant change to this model. It's theoretically possible with the current protocol - ie. you could make your own forked Chocolate Doom server that will force the players to use particular settings. File downloads would be a logical extension to this.

So I'm not averse to this idea, but it will require quite a bit of work and I don't have the time right now. If it's done I also want to see it done properly.

Danfun64 said:

The only way that will happen is if the entirety of Chocolate Doom is converted to DSL, goes closed source, and *shot*.

Uh, no. I think you don't understand what's being discussed here.

fraggle said:

Chocolate Doom's servers are basically packet forwarding servers, so "authoritarian" servers like this would be a significant change to this model.

I think I need to add a few things to my previous post, for the sake of clarity, the idea is not to give the server owner said power, but the "lobby administrator", which could be the first player that joins the lobby; he is the one that configure the settings and pick the wad file. The server owner would be given the power to set who the lobby administrator will be, for that session. Having the server owner enforce the same things for every session seems kinda pointless.

Graf Zahl said:

Of course this is a bug. If an application tells the sound system to stop, it should stop NOW.

You tell that PC, Graf!

There's plenty of apps whose programmers do not believe "Of course", based on the app's behavior. If were talking about seconds, then, yeah, it a bug. If it's a few hundred milliseconds, so what?

fraggle said:

I think you don't understand what's being discussed here.

Perhaps not. I was joking a little though.

On a more serious note, since there have been custom ipxsetup's for doom in the past, like the one (forgot its same) which allowed you to chat in the lobby. Maybe one day this feature (ensuring every resource is the same) can be implemented in Chocolate Doom.

XCOPY said:

I think I need to add a few things to my previous post, for the sake of clarity, the idea is not to give the server owner said power, but the "lobby administrator", which could be the first player that joins the lobby; he is the one that configure the settings and pick the wad file. The server owner would be given the power to set who the lobby administrator will be, for that session. Having the server owner enforce the same things for every session seems kinda pointless.

Right - I thought about both but wasn't sure which one you meant.

What you describe makes things more complicated, since it would require supporting client to client copies. The alternative is that the lobby administrator has to go to the trouble of supplying download URLs when setting up the game, which seems weird when you think about how it would work: imagine you're going to play a game with your friend; who's going to go to the trouble of finding URLs to supply on the command line? You'd just tell your friend to find and download the WAD themself.

What I was thinking of is the use case where someone wants to set up a dedicated "DWANGO5 1on1 server" (for example) that always plays with the same settings. In that case it's easier to specify eg. WADs because the server operator can take the time to configure download URLs for the WADs - it's more reasonable considering they're taking the time to set up the server anyway.

To some extent, Chocolate Doom dedicated servers in their current form are kind of pointless because all they really do is route packets. I actually stopped distributing chocolate-server binaries for this very reason. They're helpful if you have problems with firewalls and port forwarding but that's about it.

But the idea of "authoritarian servers" that always play with particular WADs or particular settings is actually kind of interesting because there is a setup cost associated with starting a multiplayer game: having to choose all the settings etc. Being able to pick a server from a list and have the game just start might actually be a nice idea. Essentially your choice of server is your choice of game settings.

Wouldn't it be kinda redundant with Doomseeker?

fraggle said:

To some extent, Chocolate Doom dedicated servers in their current form are kind of pointless because all they really do is route packets.

Packet routing can be useful if the routing between two players gives a high ping or too much packet loss, but can be avoided by changing the route, but such cases are rare (e.g. I have seen people living in Rio de Janeiro refusing to play in argentinian game servers because of high latency (~300ms) when they were supposed to have 60-100ms of latency, but that could be addressed by forcing the route through some other state at the very south of Brazil).

fraggle said:

But the idea of "authoritarian servers" that always play with particular WADs or particular settings is actually kind of interesting because there is a setup cost associated with starting a multiplayer game: having to choose all the settings etc. Being able to pick a server from a list and have the game just start might actually be a nice idea. Essentially your choice of server is your choice of game settings.

Now that I think about it, people usually does not want to go to the trouble of setting anything, so "pick up and play" is preferable.

EDIT: Does chocolate-doom support several instances being played through the same room? Last I checked, if a game was being run, nobody would be able to play until the people that connected through that room unless they left the game, but that was years ago.

That's still the behaviour yes. One game per server.

Since UTF-8 is very common today, maybe it would good to dump the ENDOOM to the terminal (if the game was started from one), and if that can't be detected at runtime, then it could be a config option. Having to close the popup screen is kind of annoying IMO.
It's possible to convert ANSI -> UTF-8, with iconv library.

It's easy enough to convert CP437 to UTF-8, but the color escapes would have to be accounted for, and they're not the same on Windows (and I don't believe it maintains an exclusive grab of the Windows command prompt).

I think it's an idea worth thinking about, though it won't be a universal solution.

hex11 said:

Since UTF-8 is very common today, maybe it would good to dump the ENDOOM to the terminal (if the game was started from one), and if that can't be detected at runtime, then it could be a config option. Having to close the popup screen is kind of annoying IMO.
It's possible to convert ANSI -> UTF-8, with iconv library.

Is it a separate window at the moment? If so, I wonder if it would make more sense to re-use the existing one. It might already be re-using the existing one, but resizing it. I was thinking about this recently. I wondered whether the ENDOOM window should match the size of your choco window - i.e., actually be the same window, and not resize (instead scale the endoom text to the window size).

Perhaps that would be less annoying?

hex11 said:

Since UTF-8 is very common today, maybe it would good to dump the ENDOOM to the terminal (if the game was started from one), and if that can't be detected at runtime, then it could be a config option. Having to close the popup screen is kind of annoying IMO.
It's possible to convert ANSI -> UTF-8, with iconv library.

I've thought about it in the past, but the biggest issue is that the font is dependent on whatever your terminal is configured to. I think there's value in always rendering with the DOS font so that you get the ENDOOM screen rendered accurately, as it originally appeared.

I'd rather not add superfluous config options if it's not necessary.

I wouldn't be sure of the font being the biggest deal. Yes, they were generally designed under the standard VGA font, but at worst, the characters will just come out a little bit funny (well, I suppose the _worst_ is not having any font with box/block elements at all, but I don't know if that is a realistic concern).

Besides the lack of color coding, take a look at this example. It should still reflect the original intent of the text art well.

                          DOOM II(tm), Hell on Earth
       ────────────────────────────────────────────────────────────────
           created by id Software and distributed by GT interative.

                                       ▓
     ▓██ ██   ▓▓▓   ▓▓ ▓█   ▓▓▓   ▓▓  ▓▓   ▓██      ▓▓███▓   ▓▓█    ▓█  ██
    ▓███████ ▓███▓ ▓██████ ▓███  ▓███▒▓█▒ ▓███▓    ▓▓██████ ▓▓███  ▓██▓ ██
    ██ ██ ██ █  ██ █ ██ ██ █  ██ █  █ ▓█  ██ ▓▓▓   ▓█ ▓▓ ▓█ ▓▓  ▓▓ █  █ ▓█
    ▓█ █▓ ▓█ ▓  █▓ █ ▓█ █▓ ▓  █▓ █  ▓ ▓█  ▓   ▓▓   ▓▒ ▒▓ ▓▓ ▓▓  ▓▓ ▓  ▓ ▓█
    ▓▓ █▓ ▓█ ▓▓█▓  ▓ ▒▓ ▓▒ ▓██▓  █  ▓ ▓▓  ▓   ▓▓   ▓▒ ▒▓ ▓▓ ▒▓  ▓▓ ▒    ▓█
    ▒▓ ▓▓ ▓▒ ▓     ▒ ▒▓ ▓▒ ▓     █  ▒ ▒▓  ▒   ▒▓   ▒▒ ▒▒ ▓▒ ▒▓  ▓▒ ▒    ▓▓
    ▒▒ ▒▒ ▒░ ▒     ░ ░▒ ▒░ ▒     ▓  ▒ ▒▓  ▒   ▒▓   ▒░ ░▒ ▒▒ ░▒  ▓▒ ▒    ▒▓
    ░▒ ░▒ ▒░ ░░  ░ ░ ░░ ▒░ ░▒ ░░ ▒  ░ ░▒▓ ░▒ ▒░░   ▒░ ░░ ▒░ ░░▒▒▒▒ ░    ▒▓
    ░░ ░░ ░░  ░░░  ░ ░░ ░░  ░░░  ░  ░  ░▒▒ ░░░░    ░░ ░░ ░░  ░░░░  ░    ░▒
    ░░                                                                  ░░
    ░░                                                                  ░░
    ░░                                                                  ░░
  ░░░░░░ ░░░░░░░░░░▒▒▒▒▒░░░░░            ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░ ░░░░░░
    ░░             ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░                     ░░
    ░░                                                                  ░░
    ░░             http://www.geocities.com/Hollywood/2299/             ░░

fraggle said:

I've thought about it in the past, but the biggest issue is that the font is dependent on whatever your terminal is configured to. I think there's value in always rendering with the DOS font so that you get the ENDOOM screen rendered accurately, as it originally appeared.

I'd rather not add superfluous config options if it's not necessary.

The windows cmd terminal also does not support blinking text, no matter how hard you try to set bit 7 of the background. Instead it supports additional background colors. So that's a total no-go.

Quasar said:

The windows cmd terminal also does not support blinking text, no matter how hard you try to set bit 7 of the background. Instead it supports additional background colors. So that's a total no-go.

Why would you even expect it to do so? Just dumping the text into it is a simple operation, but making it blink actually requires some programming effort.

I concur with leaving it as it is. Who knows what else a terminal might break if something just isn't done right.

Quasar said:

The windows cmd terminal also does not support blinking text, no matter how hard you try to set bit 7 of the background. Instead it supports additional background colors. So that's a total no-go.

I think the plan here was to use it for Unix terminals rather than the Windows command line. It is actually possible to do blinking text if your terminal supports it, eg.

echo -e "Normal \e[5mBlink"

However, it's an obscure feature and not all terminals support it (gnome-terminal doesn't for example).

In general I think the fundamental problem is that if you have a terminal it's hard to guarantee what the end result will look like. For example: does your terminal support UTF-8? does it support blinking text? will the ENDOOM screen look okay in the font that's being used? etc. All these things are unknown because there are dozens of terminal programs which can be configured in a host of different ways.

I expect that if you put the effort in you can probably show me a terminal output that looks pretty close to the current ENDOOM setup. But I doubt you'll be able to make it look good everywhere and it opens the door to a whole bunch of complicated bugs ("it looks bad with this particular terminal / font / configuration").

Graf Zahl said:

Why would you even expect it to do so? Just dumping the text into it is a simple operation, but making it blink actually requires some programming effort.

I concur with leaving it as it is. Who knows what else a terminal might break if something just isn't done right.

Never did but of course it was one of the first things I tried out of curiosity when learning how to control text attributes in cmd.exe, to my immediate disappointment :P

fraggle said:

In general I think the fundamental problem is that if you have a terminal it's hard to guarantee what the end result will look like. For example: does your terminal support UTF-8? does it support blinking text? will the ENDOOM screen look okay in the font that's being used? etc. All these things are unknown because there are dozens of terminal programs which can be configured in a host of different ways.

In ReMooD there are environment variables which are checked to determine how characters are to be drawn or if colors are to be specified. Non-ASCII and control characters are converted to close equivalents if it seems like the terminal would not support UTF-8 (that is accented e becomes e). If an "enhanced" feel seems like it would not be possible, it just drops to basic text output. For most ENDOOM screens this is fine, however for ones which use special characters it does not look as good.

However, you would very likely get far better results if you used an actual terminal library (such as ncurses) which uses the termcap files. However with the mass proliferation of vt100 compatible terminals, you can usually get away with using vt100. There are line drawing character sets for vt100, but it is not a complete DOS compatible set. There are also no funny characters such as hearts and smiling faces.

As for fonts, I should note that there are fonts which are close to the DOS feel (and includes the odd characters) but are not exact matches, such as Terminus. Only with these fonts which were meant to replace the IBM font does the ENDOOM screen look even nicer.

One thing that you can do however, is show the ENDOOM screen with aspect correction so that it would appear similarly to how Doom appears on old VGA monitors.

fraggle said:

Well, it is a "conservative" source port after all...

Because only conservatives are authoritarian.

Yeah I don't think the vt100 alternate charset buys you much. If the dude doesn't have unicode font, you could just dump the ANSI to his Latin-1 or whatever terminal, just like BitchX handled it. That at least gave the option to have the DOSEMU VGA font loaded in your terminal (this was before Unicode was common).
I guess it's possible to query the LOCALE environment in Windows at least, or something equivalent? (to check for UTF-8) Too bad about the blinking text though. But since "Microsoft <3 Linux" now, there must be a way to easily get an ANSI-compatible terminal?
As for aspect ratio, font type, font size, etc. - these are things the user has to configure himself (just like he has to configure the graphics window, to account for his hardware). Right now all you get is a small popup window. Not quite the same as DOS experience where the ANSI was displayed in its full screen glory.

Also (and I never got a chance to try this, for hardware reasons), what if someone is running in a framebuffer console? Does ENDOOM stay on screen, like it used to in DOS?

Just wanted to thank you for the SDL2 port. Running this fullscreen under Linux with SDL 1.2 was giving an unplayable frame rate for some reason.

My only complaint is that chocolate-setup no longer detects my laptop's native resolution of 1600x900, even when selecting the full screen option. Not that this is a big deal - SDL2 handles fullscreen more gracefully than 1.2.

Rohit_N said:

My only complaint is that chocolate-setup no longer detects my laptop's native resolution of 1600x900, even when selecting the full screen option. Not that this is a big deal - SDL2 handles fullscreen more gracefully than 1.2.

The SDL2 port doesn't change the screen resolution in fullscreen mode anymore. It leaves the current screen resolution as it is and scales the framebuffer to fit.

Jon, Simon: I think we should really hide the "Window Resolution" selection if "Fullscreen" is enabled. See how confusing this is.

I suspect that was the case, since exiting during fullscreen never caused a mode switch.