Chocolate Doom

[Old-Doomguy]

1 hour ago, chungy said:

It runs at 35fps just as vanilla does.

 

OK thanks, my friend. That explains the sluggishness. 

23 minutes ago, Master O said:

 

*Boss sees @Old-Doomguy playing Doom 2*

 

*Boss joins him.*

 

Yeah I've already had him join once haha 

[MadDoomerJP]

I just installed the main build from the wiki site. Everything works perfectly except the sounds. The music is fine but the sound effects cut out wayy too early. Every single one just suddenly stops midway. I downloaded the autobuild and the sounds work properly there. Is there any way to get the sounds working in the stable version tho?

[Edward850]

20 minutes ago, MadDoomerJP said:

I just installed the main build from the wiki site. Everything works perfectly except the sounds. The music is fine but the sound effects cut out wayy too early. Every single one just suddenly stops midway. I downloaded the autobuild and the sounds work properly there. Is there any way to get the sounds working in the stable version tho?

That would require time travel. The auto build is newer as it's built off the latest changes in the source and thus has bug fixes that aren't in the stable build, notably a major one with sound on some hardware.

Edited October 28, 2020 by Edward850

[MadDoomerJP]

1 hour ago, Edward850 said:

That would require time travel. The auto build is newer as it's built off the latest changes in the source and thus has bug fixes that aren't in the stable build, notably a major one with sound on some hardware.

Oh so I'm not the only one experiencing that on the main build. I thought that, since I couldnt find anyone reporting this issue, that it was fixable in the main build. So I guess there is no choice for me but to use the autobuild

[d3bugIANgl17ch]

I have been trying to compile chocolate doom 2.3.0 but there is a error saying that there is a "undefined reference to `SDLNet_GetError' " (whatever that means) and idk how to fix it. Can somebody explain whats going on please?

 

Here is the photo of the problem:

 

[fraggle]

Why 2.3.0 instead of the latest version?

[d3bugIANgl17ch]

On 11/7/2020 at 10:33 AM, fraggle said:

Why 2.3.0 instead of the latest version?

Because the latest version for me would go white a second after it opens

[drfrag]

Then use 3.0.0.

[d3bugIANgl17ch]

3 hours ago, drfrag said:

Then use 3.0.0.

it does the same thing sadly

[drfrag]

The windows version was compiled with an older SDL2 version (2.0.5). Remember that 2.3 used an older SDL version (1.2.x) and older versions of other libraries too.

I compile RUDE with 2.0.8 you could try to compile the latest master with that version instead.

[d3bugIANgl17ch]

On 11/8/2020 at 6:33 PM, drfrag said:

The windows version was compiled with an older SDL2 version (2.0.5). Remember that 2.3 used an older SDL version (1.2.x) and older versions of other libraries too.

I compile RUDE with 2.0.8 you could try to compile the latest master with that version instead.

I'm using linux, not Windows (i guess i should have mentioned that huh?).

[drfrag]

I know, my point still stands. Get SDL dev 2.0.8.

[VRonin]

Hi Guys,

I'm having a problem with libtextscrre, this is how chocolate-doom-setup.exe displays for me.

I'm on win 10.

Any advice on how to fix it?

Thanks!

 

[ZeroMaster010]

I've had some crashes with crispy doom where afterwards crispy will freeze immediately on the first window if I start it up, this freeze is fixed if I restart my computer. If I don't restart my computer I've noticed that crispy-doom-setup.exe will also freeze immediately.

 

However, chocolate-doom-setup.exe and chocolate-doom.exe v3.0.1 will also freeze/crash after a short while if not immediately as well. v3.0.0 is working fine.

Crispy doom version from v5.52 and older are also working fine after the crash. The freeze/crash on startup only appears from crispy v5.6 and onwards and the freeze on startup only happens after the initial crash while playing.

 

I'm not sure if this should be posted in the crispy doom or chocolate doom thread, but some change between v5.52 and v5.6 of crispy seems to be causing this issue, and my guess is from changes to chocolate doom. Since crispy doom v5.6 merged all changes to chocolate doom master brach up to commit https://github.com/chocolate-doom/chocolate-doom/commit/485b939b9b01e00ab47cd34a9de4a4e901d96a33 and v5.52 from https://github.com/chocolate-doom/chocolate-doom/commit/fd171dda546f38a9b7a6158ed2c3c8044e4ce72d I assume the problem might be between those, but I'm no expert.

 

I'm using windows 10, no other program is experiencing any issues as far as I can tell after the crash.

 

Similar problem seems to have been posted here a while ago for chocolate hexen:

@fabian

 

[drfrag]

Sounds like a SDL problem with your graphics driver. Try to update it or try RUDE which is up to date with Choco and uses another SDL version.

[fabian]

On 12/4/2020 at 5:40 PM, ZeroMaster010 said:

However, chocolate-doom-setup.exe and chocolate-doom.exe v3.0.1 will also freeze/crash after a short while if not immediately as well. v3.0.0 is working fine.

 

There were two lines of code changes between these two versions, both to prevent buffer overruns when establishing a network connection - so definitely unrelated. However, the build environment has been updated in the meantime. To prevent a nasty bug in SFX playback on multi-speaker systems we had to use a new initialization function for SDL_Mixer which was only available in a newer version which in turn required a newer SDL library version as well. As @drfrag already suggested, there might be an incompatibility between your graphics driver and this new SDL version. Have you tried upgrading your drivers? Alternatively, you may want to disable hardware accelerated rendering altogether by setting the `force_software_renderer` key to 1 in your config file.

[drfrag]

That software setting could be slow but i'm not sure. I compile with SDL 2.0.8 and it works well and joysticks work too.

[fabian]

Any SDL2 version >= 2.0.7 should do.

[ZeroMaster010]

My drivers are always up to date, but I will try force_software_renderer 1 and see if that works, thanks.

 

edit: force_software_renderer 1 fixes the issue, as the crash happened without it and changing it to 1 fixed it, the performance is however noticeably worse. I guess that'll do if it starts to bother me too much, the crash doesn't happen frequently enough to be a problem for short demos, and for longer demos I can use an older version since I don't need the crispy doom demo reset feature.

Edited December 14, 2020 by ZeroMaster010

[Master O]

@fabian https://github.com/chocolate-doom/chocolate-doom/issues/1337

[ReX]

I'm curious about something. Does Chocolate DooM "fix" HOM problems caused by missing upper/lower textures? I created a map with a lowering wall adjacent to a step. The lowering wall properly has lower textures on both sides, but I had accidentally forgotten to assign a lower texture to the step's linedef that is shared in common with the wall. During my playtest I realized that the step's lower texture was missing, but there was no HOM - the missing texture was being treated in the same was that (G)ZDooM treats missing upper/lower textures.

[Edward850]

Chocolate Doom doesn't fix anything. The expected behaviour of missing upper/lower textures has always been for the immediate texture plane to bleed into the missing texture area, due to the absence of anything stopping the plane drawing. It'll only HOM if no plane is drawing behind it (if your viewpoint is above or below the point where the plane draws behind the upper or lower wall). 

 

It's been a fairly well established concept since the likes of wow.wad.

Edited December 31, 2020 by Edward850

[ReX]

@Edward850: Thanks for the explanation. Because the step is 12 units high, with no appropriately lower sectors nearby for the player's viewpoint to be below the step, no HOM appears.

[peach freak]

Not sure where to post this, but after I updated Chocolate Doom from 3.0.0 to 3.0.1, my GUS stopped working. As a test, I reverted back to 3.0.0 and GUS started to work again, and then stopped after going back to 3.0.1. My GUS path hasn't been touched (C:\GUS), so I'm wondering if anyone else has encountered this issue.

[Never_Again]

There have been almost a thousand commits since v3.0.1. Why not try a daily build?

[Spie812]

I'm running into an issue where Chocolate Doom creates a savegame folder and saves the config files in the directory above the program folder.

 

 

 

 

[fabian]

1 hour ago, Spie812 said:

I'm running into an issue where Chocolate Doom creates a savegame folder and saves the config files in the directory above the program folder.

 

 

 

 

Oops: https://github.com/chocolate-doom/chocolate-doom/pull/1357

 

[peach freak]

On ‎2‎/‎28‎/‎2021 at 10:34 PM, Never_Again said:

There have been almost a thousand commits since v3.0.1. Why not try a daily build?

 

I was able to get GUS working using one of the daily builds, but I'm still on 3.0.0 for now. The other issue (and this was also an issue with the daily build that I tried) is that I get no music if I switch to Native MIDI. I don't have Timidity or a Music Pack path specified, so I imagine it would just use the Windows default MIDI synthesizer. I was using VirtualMIDISynth also so I could use a .sf2 card, but even without that running, I can't get any music running on Native MIDI.

 

Is there something I'm missing?

[Never_Again]

4 hours ago, peach freak said:

The other issue (and this was also an issue with the daily build that I tried) is that I get no music if I switch to Native MIDI. I don't have Timidity or a Music Pack path specified, so I imagine it would just use the Windows default MIDI synthesizer.

 

It does on this Win7 x64 Pro box with today's daily build, the only change from the defaults being OPL->Native MIDI for music.

Do you get music in Crispy? In Prboom-plus with the SDL option for music?

[peach freak]

2 hours ago, Never_Again said:

 

It does on this Win7 x64 Pro box with today's daily build, the only change from the defaults being OPL->Native MIDI for music.

Do you get music in Crispy? In Prboom-plus with the SDL option for music?

 

Did a quick check, in Crispy Doom, I don't get any music if I set it to the MIDI, and when I set it to SDL in Prboom Plus, I don't get music either. I do get music on Native MIDI on Chocolate Doom 2.3.0 (which is the latest release prior to version 3, right)?

 

If I had to guess, it looks like my PC is having trouble playing anything with SDL2, as everything you mentioned appears to use that while Chocolate Doom 2.3.0 doesn't. Is there a setting that somehow got corrupted on my computer somewhere?

 

This is a Windows 10 x64 20H2 box, if you're curious.

Edited March 11, 2021 by peach freak