Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

Crispy Doom 5.6.3 (Update: Oct 04, 2019)

Recommended Posts

1 hour ago, seed said:

No SDL-based source port is smooth with vsync enabled on my end, the only one that is, is GZDoom.

Well, that's because GZDoom isn't SDL-based, IIRC the renderer doesn't use SDL since like two years ago so that's why.

Share this post


Link to post
Posted (edited)
48 minutes ago, -TDRR- said:

Well, that's because GZDoom isn't SDL-based, IIRC the renderer doesn't use SDL since like two years ago so that's why.

 

Is my writing just so damn awful and easy to misunderstand these days? Because that's exactly what I meant to say.

 

Non-SDL ports are fine with vsync on my end (of which GZDoom is one), whereas only certain versions of the SDL-based ones are fine. Neither Eternity nor PrBoom+ are smooth for instance (daily builds included). Certain builds of Choco/Crispy aren't either. Doom Retro isn't.

Share this post


Link to post
14 hours ago, seed said:

No SDL-based source port is smooth with vsync enabled on my end.

 

Same here. In my case, PrBoom+ runs much much smoother overall with vsync off.

 

What even more funny is that on my laptop, PrBoom+ 2.5.1.5 has less issues and runs a bit better than 2.5.1.4 with vsync on. Whereas on my dad's laptop, PrBoom+ 2.5.1.5 has even more issues (shit performance and even some graphic glitches) than 2.5.1.4 with vsync on. Both are Windows 10. Seems like it kinda varies from pc to pc.

Share this post


Link to post
Posted (edited)
16 hours ago, -TDRR- said:

Well, that's because GZDoom isn't SDL-based, IIRC the renderer doesn't use SDL since like two years ago so that's why.

Well no wonder i don't have any issues with GZDoom! I do however have issues with basically every other source port though (mouse sensitivity issues i mean). I had no idea that GZDoom wasn't SDL based though. For me it seems like anything SDL2 based (which is everything nowadays) is just so slow that it's unusable for me.

 

And yeah, i have Vsync mouse lag/screen tearing issues in most games that i play. It seems like we all need those expensive G-Sync monitors haha!

 

Sorry for taking over your thread fabian. Crispy is an amazing port, i just wish i could use it. (i do have an older version that works fine for me, 4.3 that i sometimes use)

Share this post


Link to post
Posted (edited)
2 hours ago, CyberDreams said:

I had no idea that GZDoom wasn't SDL based though

 

That's fairly easy to tell considering the SDL files are completely absent from its folder.

 

For me, it's only certain versions of SDL that are a bit problematic, like giving me the aforementioned choppy vsync issue. I don't mind not using vsync however as I have played without it my whole life. Gsync has no point for me either, not to mention that what I care the most about monitors these days seems to be contrast and color reproduction, and no flat panel technology has what I want (ok, OLED has, but it also has many issues and are not ready to be turned into affordable consumer-level monitors. That is not happening anytime soon).

Share this post


Link to post

I think it may have to do with modern-day computers? On a garbage Celeron N2805 + Intel HD4000 i'm not having any extra choppiness from playing with vsync on in any sourceport (Unless it already ran slow on the first place, like Vavoom) PrBoom+ runs fine with it enabled.

Share this post


Link to post
11 hours ago, seed said:

That's fairly easy to tell considering the SDL files are completely absent from its folder.

you won't find any SDL dlls in k8vavoom binary build too. it is just an .exe. yet it is using SDL2. ;-)

Share this post


Link to post
Posted (edited)

I could reduce lag with GZDoom by a) copying my Doom stuff onto a RAM disk and b) putting my Doom drive (that RAM disk) on the anti-virus whitelist. That way, all the demanding HD stuff works a lot smoother.

Share this post


Link to post

So I was watching some videos of Sigil and something immediately struck me around the maze section on E3M4.

 

Are the crushers and other sounds in the world supposed to cut off the weapon's firing sounds? This looks like a bug to me.

 

 

Share this post


Link to post
35 minutes ago, seed said:

Are the crushers and other sounds in the world supposed to cut off the weapon's firing sounds? This looks like a bug to me.

Unfortunately he doesn't tell which version of Crispy he uses and which options are enabled, but as it is in the video it sounds like a bug to me, indeed. 

Share this post


Link to post
4 minutes ago, fabian said:

Unfortunately he doesn't tell which version of Crispy he uses and which options are enabled, but as it is in the video it sounds like a bug to me, indeed. 

 

My guess is the default audio settings and last stable build, but I can ask the guy nonetheless and come back with an update if he replies.

Share this post


Link to post
Posted (edited)

I've had the same problem. It was more of an issue when playing E2M8 of Nihility, where I couldn't tell monsters were attacking me from behind until it was too late. My audio settings are below.

Spoiler

 

DOOM0000.png

DOOM0001.png

 

 

Share this post


Link to post
4 hours ago, seed said:

My guess is the default audio settings and last stable build, but I can ask the guy nonetheless and come back with an update if he replies.

 

"5.3 it says in exe properties, and 32 sound channels (yup, sounds like enough channels I think)."

Share this post


Link to post
Posted (edited)

32 channels seems to be the common denominator and the culprit of the issue. My guess is that there are so many crushers and thus so many crusher sounds that the other sounds simply get drowned out.

 

Edit: I can reproduce this with 32 channels. I have a savegame where I can hear 15 (!) crushers from where I stand. If I fire a weapon now, this will be the 16th sound and it will get mixed with the other 15 identical sounds and thus will get drowned out. If I reduce the number of channels to 8, all channels might be occupied by crusher sounds. But as soon as I fire a weapon, one of them has to free its channel and thus the weapon sound will be better recognizable among merely seven other identical sounds. That's my analysis so far.

Edited by fabian

Share this post


Link to post

This has always been a tricky issue. The Linux distro was missing some sound stuff. But the problem is more fundamental:

Monsters makes sounds. Crushers make sounds. Doors make sounds. And, the player makes sounds.

 

You only have 2 physical sound channels (stereo, or 4/5 for surround sound). When you define your number of logical sound channels, the sound subsystems have to mix the logical channels into physical channels. And therein lies some problems.

 

Let's assume 32 logical channels, output to a left and right physical channel pair. In this scenario, you can have a maximum of 32 sounds playing at once. Doom sounds are typically 250 to 1000 milliseconds long.

 

So, if you walk into a room with, say, crushers (that play constantly), you only have 24 logical channels left for monsters.

Your weapon sounds need priority, cause it would be weird if your weapon didn't always make sounds.

 

Overdrive

Let's say that there are also 30 barons in this room (yikes), who will all want to scream at once. The mixer has a real dilemma: Each baron will want to scream the exact same sound at the same time. The mixer will try to play 24 of the screams, by mixing all of them together. Because it's the exact same sound at the same time, the mixed sound wave will overflow massively, causing massive overdrive/clipping/distortion. To mitigate this, the mixer has to detect this case, and effectively decrease the amplitude dynamically. How this is handled is mixer-specific.

 

I'm not exactly sure what SDL does. It could progressively turn down the source volume 24 times, or it could adjust based on the amount of detected overdrive. But, no matter what, you'll end up with reduced volumes.

 

Priority

The other issue is time. So, you're playing 24 baron sounds, and 8 crusher sounds. But what about the other 6 baron screams? And, what if the player fires the plasma gun? The engine has to do *something* to allow you to hear the plasma gun - that's a priority. Often, the engine will toss one of the older sounds.

 

But, what if there are 100 sounds? Typically, you end up with sounds being played for a few milliseconds, before being tossed for newer sounds, which sounds like monster "stuttering".

 

Somehow, you have to toss out partially played sounds, using some scheme: either by how long the sounds have already played, the sound's distance from the player, some per-sound-type priority table, or a combination of all of these.

 

Avoiding undesirable sound situations can get very complicated and ugly. With Doom sound engines, *everything* is a conflict of interest!

  • More channels = more sounds, but also more memory, less performance, more chance of overdrive/clipping issues
  • All sounds in Doom are important! It's difficult to justify not playing a nearby sound, but it also sucks to toss a recently-started sound.

What can you do about it?

Not much. But there are a few things that can improve the situation:

  • Create a priority scheme (menu sounds, then player sounds, then monster sight, monster melee, monster missie, then monster active. Plats go in there somewhere).
  • Adjust priority based on distance.
  • When all channels are being used, toss sounds based on distance, then by amount of time the sample has been active.
  • Avoid playing the same sound at the same time. Instead, increase the volume of the first sound, and skip the others.

The port author has to decide when to truncate a sound, and when to ignore a sound. It may even make sense to reprioritize, based on how hard the sound engine is being hit - maybe you switch to just playing player sounds, and monster attacks, and then, maybe prioritize those based on monster starting health (I want to hear a revenant over an imp, for example.)

 

*Good* sound code is hard, especially with Doom.

 

Share this post


Link to post

i'm having bit of a problem with this port, it will periodically freeze for about 6 seconds at time... does anyone else have such problem? or know how for fix?

Share this post


Link to post
56 minutes ago, xdarkmasterx said:

i'm having bit of a problem with this port, it will periodically freeze for about 6 seconds at time... does anyone else have such problem? or know how for fix?

 

Maybe update your graphics drivers?

Share this post


Link to post
13 hours ago, kb1 said:

*Good* sound code is hard, especially with Doom.

 

Or... you just don't have to be stupid. *sigh*

 

I just realized that when I wrote that I could hear 15 crushers, I meant that channels[0] to channels[15] were playing crusher sounds. That's 16 channels! Why on earth does it play on 16 channels at some random place on a map whereas I have enabled 32 channels? Well, it is because I still have only 16 sound channels allocated on the SDL_Mixer side. That is, I tell the engine that it's okay to play up to 32 sounds, but then only the first 16 of them are actually mixed.

 

The fix was trivial and is committed to the GIT repo. Thanks @seed and @SiFi270 for pointing me to this issue and providing examples. Fortunately, the feature is now really functional and you can actually hear your own weapon now, regardless of more than a dozen crushers working nearby. So, please excuse my yesterday's blubber, it was all moot.

Share this post


Link to post
4 hours ago, xdarkmasterx said:

i'm having bit of a problem with this port, it will periodically freeze for about 6 seconds at time... does anyone else have such problem? or know how for fix?

 

This seems to be this issue:

 

https://github.com/chocolate-doom/chocolate-doom/issues/1171

 

Could you please check if using the DLLs from the Crispy 5.5.2 release fixes it?

Share this post


Link to post

SDL is a mess recently. Let's just hope that 2.0.10 gets rid of most of these bugs. 

Share this post


Link to post
2 hours ago, fabian said:

SDL is a mess recently. Let's just hope that 2.0.10 gets rid of most of these bugs. 

A prerelease version of 2.0.10 has been made available here for those interested.

Share this post


Link to post
7 hours ago, fabian said:

Or... you just don't have to be stupid. *sigh*

Your post wasn't stupid - that's an easy issue to overlook.

I kinda went overboard with my response - I guess I was trying to open up a small dialogue about the particular difficulties of managing the playing of sounds in Doom, and how to overcome them. I'm glad you were able to fix your issue.

 

I think SDL actually does a pretty good job at handling whatever you throw at it, without having to feed it domain-specific info.

 

So, what happens if you have 32 crushers?

Share this post


Link to post
Posted (edited)
3 hours ago, kb1 said:

So, what happens if you have 32 crushers?

 

It's important to recognize that while it may seem "nice" to be able to play as many sounds as possible with minimum restriction, the player doesn't need to hear every individual instance of a sound to know that they're in a space full of a given entity. Throwing away sounds is acceptable, even wholly good, as long as you can figure out how to prioritize the sounds that are most important to a player. It's more important to convey appropriate information to the player without overwhelming them.

 

So I guess, if you have 32 crushers, you start throwing some of those sounds away. Crushers are loud and have a distinct sound, and they're also extremely visible. (Unless those crushers are in spaces with zero light, which is a dirty trick.)

 

On 6/21/2019 at 4:14 PM, kb1 said:

What can you do about it?

Not much. But there are a few things that can improve the situation:

  • Create a priority scheme (menu sounds, then player sounds, then monster sight, monster melee, monster missile, then monster active. Plats go in there somewhere).
  • Adjust priority based on distance.
  • When all channels are being used, toss sounds based on distance, then by amount of time the sample has been active.
  • Avoid playing the same sound at the same time. Instead, increase the volume of the first sound, and skip the others.

 

These are all good, frankly I'd like to see ports adopt these. One other suggestion is to dynamically mix sounds of one type in a channel - but at that point, you'd be abandoning Doom's audio mixer for a more modern system, and you'd have to think about correctly mixing and limiting the volume of audio channels. Not necessarily a bad thing, but probably not suitable for Crispy.

Share this post


Link to post
6 hours ago, bradharding said:

A prerelease version of 2.0.10 has been made available here for those interested.

 

And how is your experience with this so far? I have seen that you could remove an awkward workaround after switching to that version.

 

4 hours ago, kb1 said:

So, what happens if you have 32 crushers?

 

The same that would happen with 8 sound channels and 8 crushers: Doom's own sound priority system kicks in.

 

Code:

https://github.com/chocolate-doom/chocolate-doom/blob/master/src/doom/s_sound.c#L306

Priorities:

https://github.com/chocolate-doom/chocolate-doom/blob/master/src/doom/sounds.c#L118

 

Share this post


Link to post
6 minutes ago, fabian said:

And how is your experience with this so far? I have seen that you could remove an awkward workaround after switching to that version.

So far, no problems whatsoever. I tried experimenting with the new batch rendering feature, but that resulted in a drop in FPS. As for the workaround, I couldn't even confirm if it was necessary because I didn't experience the problems it worked around (info about it here). 

Share this post


Link to post

It is a hardware abstraction library to make it easy to port games requiring graphics, sound, input, etc across all kinds of OSes and platforms/consoles. Hypothetically it should be great, but it appears that the Windows version has been especially buggy in late releases.

Share this post


Link to post
On 6/22/2019 at 2:20 AM, Lollie said:

 

It's important to recognize that while it may seem "nice" to be able to play as many sounds as possible with minimum restriction, the player doesn't need to hear every individual instance of a sound to know that they're in a space full of a given entity. Throwing away sounds is acceptable, even wholly good, as long as you can figure out how to prioritize the sounds that are most important to a player. It's more important to convey appropriate information to the player without overwhelming them.

My counter to that is that, it kinda is important to hear a lot of sounds - that's the problem. Player sounds are mandatory, of course. But hearing doors, monster attacks, etc: Those are important too, if your play strategy depends on such things.

 

32 sounds (no pun intended) like a lot, and, it is. But I've noticed situations when I was expecting to be able to hear certain sounds, but they were either truncated early, or completely inaudible, because of priorities and other thresholds in hectic environments.

 

On 6/22/2019 at 2:20 AM, Lollie said:

So I guess, if you have 32 crushers, you start throwing some of those sounds away. Crushers are loud and have a distinct sound, and they're also extremely visible. (Unless those crushers are in spaces with zero light, which is a dirty trick.)

Stairs is another bad example. Yes, you are limited by the number of logical channels. So, you must do *something*. An easy first step is to toss multiple instances of the same sound being played at the same time, and, instead upping the volume of a single instance of the sound. That would help synchronous crushers, and sight screams of the same type of monster that sees you at the same time. Of course, this doesn't work for variable pitch effects.

 

Doom does have a primitive per-sound priority setup, which helps.

 

On 6/22/2019 at 2:20 AM, Lollie said:

These are all good, frankly I'd like to see ports adopt these. One other suggestion is to dynamically mix sounds of one type in a channel - but at that point, you'd be abandoning Doom's audio mixer for a more modern system, and you'd have to think about correctly mixing and limiting the volume of audio channels. Not necessarily a bad thing, but probably not suitable for Crispy.

 

Some ports do implement some of the suggestions, to good effect. But there always a tradeoff. The goal of the above suggestions are to minimize negative effects of such tradeoffs.

 

You cannot mix multiple sounds into a single logical channel - that's what the logical channels are for. With 32 channels, you can play 32 sounds at once, period. (Unless you implement some sort of double mix stage, which would sort of defeat the purpose of the sound mixer.) Doom itself doesn't really have a mixer itself - that's what the DMX code (which wasn't included in the Linux source release) was for. Modern ports include sound mixer library code such as SDL, OpenAL, or even DirectSound (for Windows). Ports typically don't try to roll their own sound mixer code.

 

On 6/22/2019 at 3:05 AM, fabian said:

The same that would happen with 8 sound channels and 8 crushers: Doom's own sound priority system kicks in.

 

Code:

https://github.com/chocolate-doom/chocolate-doom/blob/master/src/doom/s_sound.c#L306

Priorities:

https://github.com/chocolate-doom/chocolate-doom/blob/master/src/doom/sounds.c#L118

 

Please disregard. I re-read your post and understand that you didn't just double the channels - you had an actual bug that you fixed. Good job!

 

 

Share this post


Link to post

@fabian Sorry to ask again but I didn't get any reply to my previous question. I was trying to run the BFG Edition doom2.wad with no success with the "-episode" parameter like the page says. I thought this way Crispy Doom would look for the BFG iwad in the Steam folder like GZDoom does, but nothing happened, just regular doom2.wad (-episode 2 would warp me directly to Doom 2's Entryway with the music track from nerve's map01). I thought well maybe I have to place the BFG iwad manually in the Crispy Doom folder... and it worked (without even having to use the -epsiode parameter, just "-iwad doom2.wad"). The thing now in order to play regular doom2.wad I have to remove the BFG iwad from the Crispy folder. Is that the way to do it or am I missing something?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×