Chocolate Doom

[fraggle]

On Windows the config files will be read from your working directory unless you override with -config and/or -extraconfig.

[drfrag]

Thanks, so it's the directory of the exe. In the source is "". I don't know why it doesn't work and both use the config of the server even with -config.

[drfrag]

 I've done more testing and the config parameter is not ignored, another file with the same name is created in the folder of the server instead.

 I guess the engine go nuts due to both players using the same IP? Is the config file somehow related to the IP?

[Edward850]

4 minutes ago, drfrag said:

Is the config file somehow related to the IP?

Of course not.

[drfrag]

 I thought it shouldn't but i'm completely lost here.

Edit: it's a problem with setting the config file itself, with the full path it works with .\ it doesn't.

Edited October 16, 2019 by drfrag

[drfrag]

 I think i've found what the problem is. It works when you run it from the command line, the current working directory changes when something runs from the directory of the server. I should get the path to the executable or store the current dir in a variable, i'm going to try the latter.

[drfrag]

 Ooops! This is embarrassing, i made a stupid mistake and somehow the shortcut i was using was pointing to the server dir.

 Sorry, i've only noticed after showing the full path with _getcwd. Ouch!

 So MP on a single pc works right out of the box.

[fraggle]

Cool. Glad the mystery was resolved and you were able to figure it out.

[SmileTheory]

So I may have done a thing.

 

I'll make a pull request on github when the code doesn't look like an explosion.

[seed]

@SmileTheory Hm... red credits text on black background... is this Shareware 0.99?

 

This is so awesome, I've been waiting for support for Doom 1.2 and pre-1.2 in other ports since forever :).

 

Spoiler

Shareware Doom 0.99 let's play on Chocolate confirmed.

 

[drfrag]

On 10/17/2019 at 10:14 PM, fraggle said:

Cool. Glad the mystery was resolved and you were able to figure it out.

 Thanks, at least it was not a complete waste of time. BTW i've tried to setup a couple of joysticks and it works so in theory 4 players should be possible. But for SDL2 you'd need to allow joystick input in the background. One good thing with SDL2 is that you can resize the window freely.

[seed]

Meanwhile, I've been trying to get GUS emulation set up in Chocolate, but I cannot for the life of me get it to actually work.

 

With Native MIDI set, as described on the wiki, I'm pointing it to the config file but it's like it just doesn't pick it up no matter what. The directory I'm pointing it to in the setup tool is "D:\Doom Source Ports\Chocolate Doom (Nov 6th)\dgguspat\timidity.cfg" (that's the config file of the patches I want to use, yes; no quotation marks. I gave the full path here in case what I'm doing is plain wrong or something). But it just doesn't work, every time I start up the game it just plays as if using Native MIDI with nothing else. I've wasted one hour smashing the setup tool, to no avail. Am I just doing something supremely stupid or is it broken?

 

And if I use GUS (emulated) and point it to the path "D:\Doom Source Ports\Chocolate Doom (Nov 6th)\dgguspat", it does nothing and plays back as if Native MIDI is being used again. The lack of console is also even worse as the game does not throw me any errors or messages, so I cannot understand what's happening at all. Nothing I'm trying seems to work :( .

[fabian]

Reflex reaction: Could you try a path that doesn't contain spaces? 

[seed]

14 minutes ago, fabian said:

Reflex reaction: Could you try a path that doesn't contain spaces? 

 

*proceeds to create random new directory "zemu" and copy-pastes the "dgguspat" subfolder containing the extracted files from dgguspat.zip*

*points GUS (emulated) to D:\zemu\dgguspat*

*Native MIDI is still playing*

 

*repeats the procedure with Native MIDI, but points to D:\zemu\dgguspat\timidity.cfg instead*

*Native MIDI is still playing*

 

I tried the same thing early this morning and it just doesn't seem to want to work at all. What could I possibly be doing wrong?

[fraggle]

It sounds like you're doing everything right. If you try the latest stable release (3.0.0) from the website, does it work? I'm wondering if Timidity playback got broken at some point.

 

Another thing to try: if you use a different config, like eawpats for example, does that work?

[seed]

1 minute ago, fraggle said:

It sounds like you're doing everything right. If you try the latest stable release (3.0.0) from the website, does it work? I'm wondering if Timidity playback got broken at some point.

 

Another thing to try: if you use a different config, like eawpats for example, does that work?

 

I'll try to do both right now and return in 10-15mins to report back.

 

But for eawpats, I doubt it's going to work at all - I also have the patches used on the Xbox version of Doom and their config is "xboxpatch.cfg". It didn't work with that but I'll try anyway.

[seed]

13 minutes ago, fraggle said:

It sounds like you're doing everything right. If you try the latest stable release (3.0.0) from the website, does it work? I'm wondering if Timidity playback got broken at some point.

 

Another thing to try: if you use a different config, like eawpats for example, does that work?

 

And I'm back.

 

Unfortunately, it works. I tried both GUS (emulation) and Native MIDI, and both with a timidity.cfg and my other, xboxpatch.cfg from the other patches. Given the circumstances, and the fact that I did the exact same thing, I think it's safe to say GUS emulation is officially broken in the daily builds (with both options - GUS (emulated) and Native MIDI).

[fraggle]

Thanks, that gets us a step closer to a fix.

 

What happens if you try a daily build with SDL_mixer.dll from 3.0.0?

[seed]

13 minutes ago, fraggle said:

Thanks, that gets us a step closer to a fix.

 

What happens if you try a daily build with SDL_mixer.dll from 3.0.0?

 

Sound effects glitch horribly, and still no GUS emulation.

 

So, it's probably not SDL-related.

 

E: Actually, since I'm here, I'm going to report another issue I experienced today. I crashed once on E3M9 while playing through a Doom v1.8 IWAD (by downgrading from Ultimate Doom using @chungy's patches). I crashed immediately after I entered the area right before the tunnel with Pinkies. This was the error message I got. After that, I warped back to E3M9 and it didn't crash again, so something went funky the first time I went there.

 

Here's a short clip of the moment:

 

Spoiler

 

 

 

Edited November 7, 2019 by seed : Added another issue.

[fraggle]

If you rename chocolate-midiproc.exe to something else or move that file somewhere else, does it work?

[seed]

21 minutes ago, fraggle said:

If you rename chocolate-midiproc.exe to something else or move that file somewhere else, does it work?

 

Nope.

[drfrag]

 Since i'm running a Choco fork myself i've uploaded a test build for SmileTheory's PR dealing with 0.99 and 1.1 demo support. We need people helping to test the emulation of those versions plus 1.2 specially with old demos.
 You can download the patcher here: https://github.com/jmacd/xdelta-gpl/releases
 And the patches here: https://github.com/Doom-Utils/iwad-patches
 Command line example: xdelta3 -d -s doom.wad .\iwad-patches\doom.wad\ud-to-1.1.vcdiff doom11.wad
 You can run the engine from the command line with the iwad parameter. I extended the demo format but that should not be a problem, iwad demos play properly.

https://github.com/drfrag666/chocolate-doom/releases/download/2.5.0a/RUDE-2.5.0a-win32.zip

[seed]

Groovy @drfrag, I didn't know you were so interested in this as well :).

 

I'd try to make some demos but first I need to know something - how does your fork run on W10 (versions newer than 1709/1803). I'm asking this because it's still using SDL1, and ports based on it seem to have mouse issues now.

[drfrag]

For  me it works well under 1803. I've lost my internet connection as i've said in the LZDoom thread, i could port it to SDL2 too if i get some support to get another connection. Seems there's no interest tough.

[seed]

36 minutes ago, drfrag said:

For  me it works well under 1803. I've lost my internet connection as i've said in the LZDoom thread, i could port it to SDL2 too if i get some support to get another connection. Seems there's no interest tough.

 

I tested it myself eventually, and made a full demo of KDITD (see your own topic for RUDE). It works fine on 1909, so whatever broke in other SDL1-based versions of ports is probably different.

 

But why is the game's screen smaller than Chocolate? It occupies less space on my screen, its window is smaller, and there's black bars both above and below the game in addition to those on both sides of the screen.

[nname]

Hey, so since my PC is a bit old, I got a few questions:

1. Which rendering method does Chocolate Doom use? Is it software or some kind of hardware acceleration?

2. Do you think that 64 megabytes of video ram and a 2.16GHz cpu is enough to run Chocolate Doom? Without going below the minimum system requirements, if there are any.

[chungy]

By default, the game render is displayed on your screen via OpenGL scaling.

 

GPU capabilities and drivers are going to be your main concerns. It probably works well as-is, but if it has problems rendering the screen at all, there is a "force_software_renderer" option in chocolate-doom.cfg -- highly recommended to not set it unless you really need to.

[nname]

9 minutes ago, chungy said:

By default, the game render is displayed on your screen via OpenGL scaling.

 

GPU capabilities and drivers are going to be your main concerns. It probably works well as-is, but if it has problems rendering the screen at all, there is a "force_software_renderer" option in chocolate-doom.cfg -- highly recommended to not set it unless you really need to.

I hope you are replying to me, I'm getting kinda lost in all of these messages. Otherwise, just to make things clear you are saying that Chocolate Doom should run on my system just fine? And what about the 'family' ports such as Chocolate Heretic, are those the same thing, or do they use different rendering methods?

[chungy]

40 minutes ago, xzotikk said:

you are saying that Chocolate Doom should run on my system just fine? And what about the 'family' ports such as Chocolate Heretic, are those the same thing, or do they use different rendering methods? 

It probably does run fine on your system, but it's impossible to be certain until you try it. The Chocolate engines (Doom, Heretic, Hexen, Strife) share OS functionality (graphics, input, sound, network); if one of the games work, the others will too with identical results.

[nname]

54 minutes ago, chungy said:

By default, the game render is displayed on your screen via OpenGL scaling.

Also, I'd like to know what this means. What is the difference between OpenGL scaling and the GL renderer used by a port like GZDoom. I know that these ports are completely different, but you get what I'm trying to say.

 

I'm asking about this because I thought that Choco-Doom is supposed to be close to vanilla. And I was quite surprised when I found out that it uses OpenGL.