Crispy Doom 6.0 (Update: Mar 31, 2023)

[fabian]

Yep, crispy-heretic builds and runs and is even included in the latest release (hidden in the unsup/ directory, though).

[Mr.Rocket]

Hi,

 

I've recently added support for Crispy-Doom to Game Connector!

 

Cheers

[Grain of Salt]

1 hour ago, fabian said:

Yep, crispy-heretic builds and runs and is even included in the latest release (hidden in the unsup/ directory, though).

 

Not hexen, though?

[Jon]

No

[carburetor]

Hi, I'm playing Alien Vendetta on the 5.2 Win binaries, and I've ended up with a savegame on MAP06 with a "ghost" chaingunner? He takes no damage except for rocket splash with all hitscans and projectiles going through him, generally tries to follow a correct path but clips through walls and across untraversable floor heights if you lead him around, but still appears to be solid on approach? I found the map also reloading (consistently, for a while, after player death) in two different spawn spots, one behind the cyberdemon, one in the switch room by the red door, but I don't seem to be able to replicate that now.

 

Doom 2 BFG IWAD, -file av.wad. Savegame here; chaingunner is lurking in the yellow key slime pit.

[fabian]

It is possible that the chaingunner has been crushed and then resurrected by an archvile, which makes him lose all his "body geometry" and allows him to no-clip through walls. If you enable translucency, does he appear translucent? 

 

Regarding respawning after player death, it you keep holding the "run" button during resurrection, you will respawn from the latest savegame on that map. Maybe this is it? 

[carburetor]

1 hour ago, fabian said:

It is possible that the chaingunner has been crushed and then resurrected by an archvile, which makes him lose all his "body geometry" and allows him to no-clip through walls. If you enable translucency, does he appear translucent?

 

He does! No difference between translucency for projectiles, items or both.

However... there are no arch-viles on that map (according to the console readout in ZDoom).

 

1 hour ago, fabian said:

Regarding respawning after player death, it you keep holding the "run" button during resurrection, you will respawn from the latest savegame on that map. Maybe this is it?

 

It isn't, but I figured it out while testing this! When resurrecting normally (with the "use" key) it randomly selects from the deathmatch spawn points. Edit: at least, it did; seems to be utterly random, but when it does it will do it consistently until the game is quit.

Edited July 5, 2018 by carburetor

[fabian]

You might have experienced an INTERCEPTS overrun then.

[fabian]

On 7/5/2018 at 2:00 PM, carburetor said:

However... there are no arch-viles on that map (according to the console readout in ZDoom).

Well,,, according to Doomwiki there are 2 on this map!

[carburetor]

10 hours ago, fabian said:

Well,,, according to Doomwiki there are 2 on this map!

 

Behold the two tiers of human error in which I both misread the readout and forgot I already killed one of them in the savegame.

I did a flythrough in GZDoom Builder and worked out that I must have tripped the linedef that teleports one of the archviles in from a dummy room, who then revived a squashed chaingunner while setting up backstage for a reprise assault behind the yellow door, and then briefly backtracked long enough that it appeared as an extra on set in the horde behind the red door, before saving the game.

 

An intercepts overflow, while that's undefined behavior, would be more likely to cause the all-ghosts bug than affect a single monster, would it not? But then what else would allow for randomized deathmatch-start resurrections? I took a screenshot of one while I had the chance (in a window due to no defined screenshot button) but still cannot replicate it.

 

[Dwaze]

On 7/5/2018 at 12:53 PM, carburetor said:

I found the map also reloading (consistently, for a while, after player death) in two different spawn spots, one behind the cyberdemon, one in the switch room by the red door, but I don't seem to be able to replicate that now.

I had something similar happening when playing AV on prboom+ 2.5.1.5. If I start up prboom (without -warp or -loadgame), after a while a deathmatch demo starts playing and from there on the game thinks you're playing deathmatch or something, spawning the player on dm spawns. If I was quick enough to launch a map before the demo starts playing, I didn't had this problem. Maybe it's the same problem.

 

edit: It doesn't happen when starting a new game, but it does when loading one.

Edited July 7, 2018 by Dwaze

[fabian]

@carburetor Note that you have the "FRAG" widget active in the status bar instead of the usual weapon roster.

 

There is already code in G_DoLoadGame() that resets the "netgame" variable when loading a savegame from the menu, but it currently does not reset the "deathmatch" variable. This is fixed now, thanks!

 

https://github.com/fabiangreffrath/crispy-doom/blob/master/src/doom/g_game.c#L1885

[carburetor]

Good stuff. @Dwaze got me thinking similar issues live upstream too; Chocolate Doom seems to think that same deathmatch demo is a live netgame and refuses to load games. ^{(Bug report.)}

Edited July 7, 2018 by carburetor

[Paar]

I'm one of those who experience weird sound problem in 5.2 where everything is pitched so high it's like a parody of Doom. The music plays fine (General MIDI). Tried Chocolate Doom and sounds play fine. I didn't have time to test previous versions but I think I had no problem in version 5.0.

 

By the way I like the option to uncap the framerate with vsync on but this solution introduces input lag. Is there a way to eliminate it?

[fabian]

@Paar I guess you are using Windows 10, right. Have you tried the steps I outlined here?

 

1 hour ago, Paar said:

By the way I like the option to uncap the framerate with vsync on but this solution introduces input lag. Is there a way to eliminate it?

 

The problem seems to be that once a frame has been drawn to screen, the next frame is rendered immediately after, but then has to wait for the next VSync until it gets drawn to screen. So, there is always a certain several-ms lag between the rendering of the scene and its drawing to screen. I am not sure how to fix that, though. :(

[Paar]

8 hours ago, fabian said:

@Paar I guess you are using Windows 10, right. Have you tried the steps I outlined here?

The problem seems to be that once a frame has been drawn to screen, the next frame is rendered immediately after, but then has to wait for the next VSync until it gets drawn to screen. So, there is always a certain several-ms lag between the rendering of the scene and its drawing to screen. I am not sure how to fix that, though. :(

 

Regarding the sound issue setting the variable to "directsound" solved the problem. Thank you for the tip. Is there a way to make it convenient for other players so they don't need to play with this setting?

 

Vsync is unpleasant because Doom is a type of game where you need to utilise fast reflexes. And the input lag spoils the fun. Personaly I prefer some minor screen tearing with zero lag. Would FPS limit solve the issue?

[kb1]

9 hours ago, Paar said:

 

Regarding the sound issue setting the variable to "directsound" solved the problem. Thank you for the tip. Is there a way to make it convenient for other players so they don't need to play with this setting?

 

Vsync is unpleasant because Doom is a type of game where you need to utilise fast reflexes. And the input lag spoils the fun. Personaly I prefer some minor screen tearing with zero lag. Would FPS limit solve the issue?

I guess you could check input during the VSYNC wait. But, something seems wrong: Can anyone really detect input lag when it's being sampled at 35Hz? The most insanely fast guitar shredders can't pick faster than 18 notes/per second or so. Could something else be happening? It's not so easy to detect either, I wouldn't think.

[Paar]

4 hours ago, kb1 said:

I guess you could check input during the VSYNC wait. But, something seems wrong: Can anyone really detect input lag when it's being sampled at 35Hz? The most insanely fast guitar shredders can't pick faster than 18 notes/per second or so. Could something else be happening? It's not so easy to detect either, I wouldn't think.

 

It's not noticable when using capped framerate, only when using uncapped at 60Hz. I can tell that there is input lag when played at 35fps but it's so low that it doesn't bother me.

[kb1]

19 hours ago, Paar said:

 

It's not noticable when using capped framerate, only when using uncapped at 60Hz. I can tell that there is input lag when played at 35fps but it's so low that it doesn't bother me.

That's strange, because 60Hz is, of course, faster than 35. But, it's not twice as fast, like 70Hz would be. Depending on how the uncap code works, it's possible that the renderer doesn't always have a new frame ready in time for VSync, which could have the effect of showing the same frame twice sometimes, which would give the illusion of input lag. It's a concept that's difficult to mentally visualize, for me, anyway. And, programmatically, it's an interesting issue. The problem may disappear with a 70Hz monitor. If someone on the forums has a 70Hz monitor, that might be a nice test. If someone has both a 60Hz and 70Hz monitor, that'd be an even better test environment.

[galileo31dos01]

Here's an odd situation that has been happening with the last release: you know when doomguy is running, the weapon is bobbing and so does the screen. Well, sometimes, and it's hard to tell when or why, but sometimes the screen doesn't bob, sort of like in Wolf3d. So here is a savestate of a visual example of that happening:

 

ndcpmap06.zip

 

The wad is Newdoom Community Project (ndcp.wad), map 06, skill 4, second savestate. It isn't a demo because the map has an issue with a gate not opening in its entirely, possibly due to testing on a ZDoom port. Notice that the screen bobs at the place doomguy is standing, follow the green flat and then see how the screen stops bobbing, go through the opened door to observe better. I hope you can see it too :s

[Julia Nechaevskaya]

Got it reproduced. Another place where you can easily see it (same map): https://youtu.be/z3AwLW_4TsU

 

Not sure what is happening, but it's definitely not a DEHACKED lump issue, there only [STRINGS] lumps. Could it be a BLOCKMAP issue then?

[fabian]

Is this s Crispy-specific issue or do other ports (e.g. prboom-plus -complevel 2) show this as well?

[galileo31dos01]

PRBoom+ complevel 2 or 9 didn't show this, neither ZDoom or Crispy 4.2, so far only 5.2. 

 

17 hours ago, galileo31dos01 said:

Well, sometimes, and it's hard to tell when or why, but sometimes the screen doesn't bob, sort of like in Wolf3d.

 

With this I meant in other wads like Zone 300 and System Vices, both authentically vanilla. It happens randomly, or not, for example if you start that map from ndcp.wad, turn idclip and go to the area from my savestate, flip the skull switch, then open the wide door and stick to the wall in front of you, you'll hear like a lift raising and lowering (which I assume correspond to the lifts with shotgunners on them, or mancubi if they died), the moments where the lift stops are when the screen bobs, and when it's moving the screen doesn't bob. Although if both lifts are working then the screen never bobs... I wish I can give a proper example but that's all I have now :/

[fabian]

I think I've nailed it down. The problem should also be reproducible in Doom Retro, can you confirm that?

[galileo31dos01]

Doom Retro? I never used that :s

 

Ok, I found another example. It just happened when I opened the first door in ndcp.wad map 09, while it's open=screen bobs, while it's opening or closing=screen doesn't bob. Happens specifically in that sector. Let me search Doom Retro and test it.

[bradharding]

23 minutes ago, fabian said:

I think I've nailed it down. The problem should also be reproducible in Doom Retro, can you confirm that?

I haven't been able to reproduce it.

[galileo31dos01]

Me neither, checked both examples and the issue doesn't happen.

[fabian]

14 hours ago, bradharding said:

I haven't been able to reproduce it.

Hm, that's interesting, because the culprit is the following code which we both share in our source code:

 

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

https://github.com/bradharding/doomretro/blob/master/src/p_map.c#L1143

 

Anyway, I have applied a fix for it and now it should be fine.

[Jon]

Debian package: https://tracker.debian.org/pkg/crispy-doom

[fabian]

22 hours ago, Jon said:

Debian package: https://tracker.debian.org/pkg/crispy-doom

I am glad you did this, thank you! I'll add myself to Uploaders soon. ;)