Crispy Doom 6.0 (Update: Mar 31, 2023)

[fabian]

On 8/24/2018 at 6:03 PM, Julia Nechaevskaya said:

Checked just now dev Crispy build with dev Choco DLLs - everything is fine.

 

Thanks for checking, the directsound backend seems to be reliable across many SDL library versions.

 

On 8/24/2018 at 6:03 PM, Julia Nechaevskaya said:

But now DLLs seems to be same in both dev Crispy and Choco?

 

It has always been like this. Choco and Crispy daily builds as well as Choco releases all use SDL2.0.5 libraries, whereas Crispy releases use SDL2.0.8.

[kb1]

On 8/16/2018 at 7:15 PM, bradharding said:

Windows 10 Home Build 1803, WASAPI, getting the "cartoon" sounds. I believe I got a similar report from a user after the release of SDL 2.0.6. After a bit of research on https://discourse.libsdl.org/ I force Windows to use the DirectSound driver (putenv("SDL_AUDIODRIVER=DirectSound")). Although that user hasn't got back to me, nobody else has reported anything similar.

 

Edit: Switching to WASAPI in DR by not setting the SDL_AUDIODRIVER environment variable gives me the cartoon sounds.

Is there any way that somebody can record these, like with a cellphone, and upload them? I'd love to hear these "cartoon" sounds, if nothing else, for an understanding of what is happening, and how to identify that it has occurred.

 

To anyone that can, thank you in advance!

[MAJ]

kb1, here is a link.

[kb1]

7 hours ago, MAJ said:

kb1, here is a link.

Ah, thank you!

 

Ok, I had a listen. They are not "cartoony" per se, they are high-pitched. It's kinda cool :)

If I had to guess, I'd say the sound renderer thinks the data is:

• a higher sample rate than it is
• 32-bit or 16-bit vs. 8-bit
• stereo vs. mono
• surround vs. mono
• any or all of the above, but probably just one

It sounds 2 octaves higher, suggesting a 4 to 1 speedup (suggesting 32-bit vs 8-bit, or surround vs mono). Is it solved?

 

[chungy]

Wow... I never imagined it would sound so bad. That's hilarious xD

[ckjb1969]

Now everyone can see how annoying it is if you're trying to play the game. Its a very big distraction, and why us with the actual problem, have searched and asked for a fix. I for one am glad to be able to hear the sfx as it was intended now thanks to fabian. big thumbs up!

[kb1]

So, it is fixed? Or do you switch backends for a workaround? If it's not fixed, I have a suggestion:

Make a cmd-line switch "-soundtest n" that accepts an int. Then change the code that writes sound lump data to the sound buffer as follows:

 

Assuming sound lump bytes = {0, 63, 127, 191, 255}

When n=0, write data as-is: {0, 63, 127, 191, 255}

When n=1, write {0, 0, 63, 0, 127, 0, 191, 0, 255, 0}

When n=2, write {0, 0, 63, 63, 127, 127, 191, 191, 255, 255}

When n=3, write {0, 0, 0, 0, 63, 0, 0, 0, 127, 0, 0, 0, 191, 0, 0, 0, 255, 0, 0, 0}

When n=4, write {0, 0, 0, 0, 63, 63, 63, 63, 127, 127, 127, 127, 191, 191, 191, 191, 255, 255, 255, 255}

 

Have someone like MAJ try each one, recording the output, and have them post the results. This would confirm my theory, and provide a clue on a possible workaround. My guess is that either n=2 (8->16 bit), or n=4 (8->32 bit) will sound close to normal, with a small amount of distortion. n=1 or n=3 might sound better, or will have an endianness issue making it way too quiet, or way too loud. It's just a guess based on MAJ's upload, and this method provides you with a pretty easy way to remotely test it. Wow, what an interesting issue. Good luck solving it quickly.

[fabian]

On 8/31/2018 at 2:52 AM, kb1 said:

So, it is fixed? Or do you switch backends for a workaround?

 

The fact that sounds play back properly on some systems with the WASAPI backend but not on others leads me to think that this is a driver issue on these specific systems - or a mismatch between SDL2's WASAPI backend code and some other layers of Windows' audio stack. Anyway, this is not a Crispy-specific issue, so I don't see any sense in trying to "fix" it in Crispy. In the end, what you suggest is just another workaround for broken backend code - just as switching the actual backend is a workaround for that.

 

After all, this is an SDL2 issue, but until I found a reproducible use case, I don't see how I could issue a meaningful bug report upstream. :(

[MAJ]

I have few questions:

1. How I can set the pixel perfect 16:10 aspect ratio? fullscreen_width\height parameters don't give any result.

2. How to play custom maps in multiplayer? I add wads in settings app, create a game, then my friend connect to me and see classic Doom and get quick disconnect.

On 8/31/2018 at 3:52 AM, kb1 said:

Have someone like MAJ try each one

I'm not a programmer, sorry.

[fabian]

21 minutes ago, MAJ said:

1. How I can set the pixel perfect 16:10 aspect ratio? fullscreen_width\height parameters don't give any result.

 

You'll have to disable "Aspect Ratio Correction".

 

21 minutes ago, MAJ said:

2. How to play custom maps in multiplayer? I add wads in settings app, create a game, then my friend connect to me and see classic Doom and get quick disconnect.

I'm not a programmer, sorry.

 

The clients joining the game will have to add the same WADs as you did when starting the server.

[MAJ]

1 hour ago, fabian said:

You'll have to disable "Aspect Ratio Correction".

I always turn it off, but there is no use.

1 hour ago, fabian said:

The clients joining the game will have to add the same WADs as you did when starting the server.

He did the same what I did and get classic Doom with disconnect.

[doomaddict82]

would it be possible to add a level-timer in game (not at the map stats screen) in the upper right corner a la cndoom in the next crispy version?

@fabian

[fabian]

2 hours ago, doomaddict82 said:

would it be possible to add a level-timer in game (not at the map stats screen) in the upper right corner a la cndoom in the next crispy version?

@fabian

 

It's already there, but only if you record or play a demo. You'll have to explicitly enable it in the Crispness menu, though.

[MAJ]

I tryed to set 16:10 aspect ratio in dev build and got this. I hope in next version it will be fixed.

[kb1]

On 9/2/2018 at 2:05 PM, fabian said:

 

The fact that sounds play back properly on some systems with the WASAPI backend but not on others leads me to think that this is a driver issue on these specific systems - or a mismatch between SDL2's WASAPI backend code and some other layers of Windows' audio stack. Anyway, this is not a Crispy-specific issue, so I don't see any sense in trying to "fix" it in Crispy. In the end, what you suggest is just another workaround for broken backend code - just as switching the actual backend is a workaround for that.

 

After all, this is an SDL2 issue, but until I found a reproducible use case, I don't see how I could issue a meaningful bug report upstream. :(

It wasn't a fix - just a way to decipher what the issue was. It seemed interesting to debug, that's all. And, it might have provided insight that might lead to a possible fix. Just a suggestion.

[kb1]

On 9/3/2018 at 6:02 AM, MAJ said:

I'm not a programmer, sorry.

You wouldn't have had to be, but thanks for replying.

[Danfun64]

@MAJ This issue carries over from upstream Chocolate Doom. Chungy and Fragglet, for some inexplicable reason, decided to prioritize people who wanted the image stretched to the whole screen than people who wanted aspect ratio correction turned off to make the aspect ratio 8:5. If you want the correct incorrect aspect ratio, you'll need to turn on integer scaling. While it won't fill the entire vertical resolution, it'll still be in the correct incorrect aspect ratio.

Edited September 5, 2018 by Danfun64

[Dwaze]

I recently started using Crispy Doom 5.3 and on my machine in some cases, view bobbing gets disabled.

This happens when you're in a sector:

    That functions as a lift or (when it is moving),

    has its floor raising/lowering or,

    has its ceiling raising/lowering (also crushers)

(I haven't tested all actions, just a few here and there)

 

I made this test map that shows this behaviour:

The blue switches in the first room will lower/raise the floor (action 60, 69) and the green switch is a lift lower/raise (62).

If you walk over the red carpet it will raise the ceiling (40) of the 2nd room and the red switch is a perpetual crusher (49).

If i'm in any of the affecting sectors, view bobbing gets disabled for me.

Does this happen to anybody else, or is it just me?

If I run the tests in Chocolate Doom view bobbing is enabled in all of those cases.

 

viewbob-wad.zip

-iwad doom2.wad -file viewbob.wad -warp 01

Plutonia map02 is also a good example of a floor lower.

Thanks!

 

 

Edited September 5, 2018 by Dwaze

[fabian]

@Dwaze Thank you very much for this nearly perfect bug report! You are right that the player's viewz is recalculated if he is standing within a sector that has a moving ceiling of floor, but the view bob is omitted in this calculation. The code is here:

 

https://github.com/fabiangreffrath/crispy-doom/blob/master/src/doom/p_map.c#L642

 

Originally, in order to achieve what I want (i.e. smooth update of the player's view height while standing on a moving floor that just stopped moving) I should rather call P_CalcHeight(). This function, however, is supposed to get called only once per tic (because of the way it changes some variables).

 

I am not entirely sure what to do now, but since the code has caused another similar bug only recently and the glitch that it is supposed to fix isn't that glaring, I am inclined to remove it entirely instead of band-aiding around it another time. :S

[Dwaze]

No problem, thank you for this port and its updates. I really like the addition of the timer for demo playback.

I trust you on the technical details of the code haha, although I understood the highlighted line.

I can still use an earlier version (v5.1 viewbobbing looks ok), so it's not urgent at all.

[kb1]

6 hours ago, fabian said:

I am not entirely sure what to do now, but since the code has caused another similar bug only recently and the glitch that it is supposed to fix isn't that glaring, I am inclined to remove it entirely instead of band-aiding around it another time. :S

I can't offer any advice here - only sympathy for trying to fix one very messed up aspect of Doom gameplay: view bobbing. View bobbing has been problematic all along, and when the Boom/MBF team added ice/sludge sectors and item carrying conveyors, it got worse and worse. It screws thing up when falling, when dying, when switching weapons, and all the aforementioned situations. When transitioning between situations, you either have to wait for the bob to reach a certain point in its cycle, or risk seeing a jarring transition. You end up chasing a moving target, figuratively and literally.

 

What glitch were you trying to solve? Were you preventing bobbing that was occurring because the player was moving along the Z axis? I must admit, I've seen and caused so many changes to bobbing, that I honestly don't understand exactly what it does and affects, so I am curious to read about fixes and improvements to bobbing.

[fabian]

11 hours ago, kb1 said:

What glitch were you trying to solve?

 

If you are moving up on an elevator, and then the elevator stops, your view height is updated only one tic later than when the elevator stopped moving. It's barely noticable, but once you've seen it, it cannot be unseen.

 

The narrow elevator in MAP01 is a nice example: Stand on it so you can see the elevator's edge. And after it stops moving up, your view will move another step up just one tic later.

[kb1]

11 hours ago, fabian said:

 

If you are moving up on an elevator, and then the elevator stops, your view height is updated only one tic later than when the elevator stopped moving. It's barely noticable, but once you've seen it, it cannot be unseen.

 

The narrow elevator in MAP01 is a nice example: Stand on it so you can see the elevator's edge. And after it stops moving up, your view will move another step up just one tic later.

Well, no, I wasn't aware of that...but now I'm not going to be able to un-see it either, damnit!  :)

 

I'm curious now - Is it that bobbing is halted when the player is on a moving platform? If that's the case, why not set a one-time flag that enables the viewheight fix when the platform *starts* moving, for that tic only, then reset the flag? It looks like your code adjusts viewheight for every tic that the sector is moving. Is that necessary? (I know the player mobj has to move with the sector, but would it make more sense to adjust viewheight at the beginning of the sector move vs. throughout, or at the end?). Just an idea - no clue how it would work out.

 

The player's view is supposed to bob as the result of lugging around a big gun. It's very difficult to maintain this action during the course of a game, as it is affected by player XY movement speed, and it affects height, as does standing on moving platforms, climbing stairs, jumping/falling, switching weapons, firing weapons...the list goes on and on.

 

Worse is that Doom vets have seen this effect for many years now, so doing fixes to it will be jarring for some, no matter what you do.

 

Hope you can resolve it to your satisfaction. I'd like to have a web series just on bobbing, kinda like Linguica's series on player movement. I'd also love to understand the effect enough to be able to perfect it, but it is as much artistic as it is nostalgic as it is "realistic". Good luck!

[fabian]

I think I'll modify P_CalcHeight() a bit to provide a "harmless" call.

[maxmanium]

I think I've discovered a minor bug in Crispy Doom -- it wasn't present in any other source port that I tried. During states of invulnerability (didn't matter if I used IDDQD or the powerup) STFKILL0-4 are never displayed in the status bar when holding down fire -- only STFGOD0.

[fabian]

10 hours ago, maxmanium said:

I think I've discovered a minor bug in Crispy Doom -- it wasn't present in any other source port that I tried. During states of invulnerability (didn't matter if I used IDDQD or the powerup) STFKILL0-4 are never displayed in the status bar when holding down fire -- only STFGOD0.

It's not a bug, it's a feature. ;) Others before you have complained that "god" shows emotions during firing and thereby loses the golden gloss in his eyes.

[Grizzly]

Please note how the windows volume mixer changes the audio of the entire .exe when I change the music volume.  Although it's not in the video, if you change Crispy's volume in the audio mixer rather then in game, the game will play music even if music is entirely turned off.

 

The latest development builds don't have this issue (although they do deviate from Chocolate Doom in behaviour by having a seperate midiprocessor that has it's volume adjusted instead). This issue also doesn't occur if you're using OPL3 music emulation in either the development or the release version. This problem also doesn't appear in Chocolate Doom.

 

It's almost as if the 5.3 Crispy Doom is trying to play all of it's audio through whatever it's using for playing music. Might be a lead into what's been causing those audio issues for people.

[Dwaze]

3 hours ago, Grizzly said:

Please note how the windows volume mixer changes the audio of the entire .exe when I change the music volume.  Although it's not in the video, if you change Crispy's volume in the audio mixer rather then in game, the game will play music even if music is entirely turned off.

 

The latest development builds don't have this issue (although they do deviate from Chocolate Doom in behaviour by having a seperate midiprocessor that has it's volume adjusted instead). This issue also doesn't occur if you're using OPL3 music emulation in either the development or the release version. This problem also doesn't appear in Chocolate Doom.

 

It's almost as if the 5.3 Crispy Doom is trying to play all of it's audio through whatever it's using for playing music. Might be a lead into what's been causing those audio issues for people.

I had the same problem until I copied the crispy-midiproc.exe from unsup folder to the same level as where crispy-doom.exe is.

That solved it for me.

[fabian]

I guess I'll be able to add the midiproc exe back into the top-level directory from the next release on.

[MAJ]

fabian, also add please libsamplerate option to in-game menu or disable this shit function by default like in choco. And I hope you restore 16:10 aspect ratio without picture cut, now its no way to turn it on correctly.