Crispy Doom 6.0 (Update: Mar 31, 2023)

[MugMonster]

I was playing Pharaoh with the GOG version and noticed the anthology patch doesn't seem to fully work. the map has 2 bugs, the yellow key accidentally tagged multiplayer only, and a sergeant who wakes up early and blocks the teleporter ambush at the end from happening. TNT31.WAD fixes both of those, but apparently the patched version only fixes the key and not the teleporter. I didnt notice in other ports because zdoom fixes the problem internally by building its own nodes, but it happens in chocolate/crispy. I know this isnt really a big issue, because you can still just use TNT31, but I was hoping I wouldnt have to hang on to that since the patch existed. I know chocolate won't touch it because that leaves vanilla bugs alone, but I'm wondering if this is something crispy could or would address

[VGA]

Mr.Unsmiley said:

I was playing Pharaoh with the GOG version and noticed the anthology patch doesn't seem to fully work. the map has 2 bugs, the yellow key accidentally tagged multiplayer only, and a sergeant who wakes up early and blocks the teleporter ambush at the end from happening. TNT31.WAD fixes both of those, but apparently the patched version only fixes the key and not the teleporter. I didnt notice in other ports because zdoom fixes the problem internally by building its own nodes, but it happens in chocolate/crispy. I know this isnt really a big issue, because you can still just use TNT31, but I was hoping I wouldnt have to hang on to that since the patch existed. I know chocolate won't touch it because that leaves vanilla bugs alone, but I'm wondering if this is something crispy could or would address

Crispy doesn't do map fixes.

You should fix your iwad:
https://www.doomworld.com/vb/doom-general/71834-iwad-converter/

Make it the PSN version, it has the alternative health gfx, too! :D

[MugMonster]

my iwad is the id anthology version so I thought it was already fixed? also I thought this was an engine error rather than a map error, and Crispy can fix engine errors that Chocolate doesn't, right?

http://doomwiki.org/wiki/Sleeping_shotgun_guy_in_MAP02_%28Doom_II%29 I'm pretty sure it's the same thing as this

[fabian]

VGA said:

Crispy doesn't do map fixes.

Well, it does fix errors that would lead to misbehaviour or crashes if left untouched.

But I won't open the can of worms and start to do convenience fixes in IWADs. I know some ports do this, but I can't stand it.

Mr.Unsmiley said:

http://doomwiki.org/wiki/Sleeping_shotgun_guy_in_MAP02_%28Doom_II%29 I'm pretty sure it's the same thing as this

I know this bug and it would be trivial to fix. However, this would immediately break demo compatibility and netgame compatibility with Choco. So, no, I am not going to change this.

In your previous reply you mention that

zdoom fixes the problem internally by building its own nodes

but I am not sure how this is related?

[MugMonster]

fabian said:

I know this bug and it would be trivial to fix. However, this would immediately break demo compatibility and netgame compatibility with Choco. So, no, I am not going to change this.

Alright, that's kinda what I was expecting. I dont know anything about programming but I understand what is and isnt worth fixing so I accept that

In your previous reply you mention that
but I am not sure how this is related?

I dunno I'm just mentioning what it says on the Doomwiki page for the map
"source ports that build their own nodes or use different line-of-sight algorithms may fix this bug silently."
but if it's not relevant to anything then feel free to disregard of course!

[VGA]

Mr.Unsmiley said:

my iwad is the id anthology version so I thought it was already fixed?

According to the doomwiki not all of the id anthology versions have the bugfixed TNT.WAD
http://doomwiki.org/wiki/TNT.WAD

I have patched my IWAD and you should, too. Because you obviously have the buggy version and Crispy Doom is not responsible for these 2 bugs. The map is buggy.

[chungy]

Do you have multiple copies of Final Doom installed?

Crispy shares the IWAD search paths from Chocolate, and it includes search the DOS, Steam, and GOG.com installation folders. If you have multiple copies, maybe it's just picking up an unintended version.

[plums]

I saw a few updates on the github tracker. I don't have access to my desktop computer for a few days, and I don't have the password to my github account on this laptop & don't feel like doing a password reset, so I'm just going to post a few thoughts here...

OK, got sky transfers running. They don't animate, though. :/

I think this is fine, the only time I've seen sky transfers in limit-removing maps was just to change the sky from one map to the next, and not for any special effects. That's an appropriate division between "limit-removing with optional extra features" and more advanced map formats anyhow, I think.

What is still missing is to automatically un-pause when a game is saved or a message is confirmed.

It would be nice to implement but it doesn't really bother me, all it requires is one more keypress from the player. Much less severe an issue than "forgetting to pause before saving ruins your demo".

Hm, and stdout/stderr don't reveal anything useful in all these crashes?

Nope, they have nothing unusual in them at all.

I think the crashing might have something to do with the uncapped framerate option, but I haven't had time to investigate thoroughly.

[fabian]

plums said:

I think this is fine, the only time I've seen sky transfers in limit-removing maps was just to change the sky from one map to the next, and not for any special effects. That's an appropriate division between "limit-removing with optional extra features" and more advanced map formats anyhow, I think.

I have to stand corrected, they animate but don't scroll. So far I have only tested with SKY.WAD from MBF's examples.zip, and it works as expected -- except for the scrolling which I haven't implemented, that is.

plums said:

It would be nice to implement but it doesn't really bother me, all it requires is one more keypress from the player. Much less severe an issue than "forgetting to pause before saving ruins your demo".

I don't think I am going to touch this any further. Any fix would be more hackish than that special situation deserves. The next logical step would be to implement MBF's distinction between basetic and gametic, but that's another complicated mess on its own.

plums said:

I think the crashing might have something to do with the uncapped framerate option, but I haven't had time to investigate thoroughly.

I hope you'll find something reproducible soon. Any chance you build Crispy on your own and run it through a debugger until it crashes? I know this is a bold request, sorry.

[plums]

fabian said:

I hope you'll find something reproducible soon. Any chance you build Crispy on your own and run it through a debugger until it crashes? I know this is a bold request, sorry.

If the uncapped framerate doesn't turn out to be the issue, I will try this. It will be a few days still until I am back on my desktop and can do anything though.

I'll close the "saving during demos" issue then too, but you may do it earlier if you want.

[Breeder]

I had this working on my Rapspberry Pi(s), but now I can only get it to work under Rapsian, but not Retropie.

Under Retropie it says the following when I try to run either FreeDOOM wad.

I_Init: Setting up machine state.
OPL_Init: Using driver 'SDL'.
NET_Init: Init network subsystem.
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [ ............................................
P_Init: Init Playloop state.
R_TextureNumForName: 2DIRT not found
P_InitPicAnims: bad cycle from SW1EXIT to 2DIRT

[fabian]

This might be a char signedness issue. Does it help if you change the type of the "istexture" element of struct animdef_t in doom/p_spec.c from "char" to "signed char"?

[Breeder]

I see the code but don't understand what to do:

//
// Animating textures and planes
// There is another anim_t used in wi_stuff, unrelated.
//
typedef struct
{
boolean istexture;
int picnum;
int basepic;
int numpics;
int speed;

} anim_t;

//
// source animation definition
//
// [crispy] change istexture type from int to char and
// add PACKEDATTR for reading ANIMATED lumps from memory
typedef struct
{
char istexture; // if false, it is a flat
char endname[9];
char startname[9];
int speed;
} PACKEDATTR animdef_t;



#define MAXANIMS 32

// [crispy] remove MAXANIMS limit
extern anim_t* anims;
extern anim_t* lastanim;

[fabian]

Breeder said:

char istexture; // if false, it is a flat

Type "unsigned" right before "char" in this line and compile anew.

[Breeder]

EDIT: unsigned does not work, but signed does. :)

OK, so how come it worked on previous versions of Retropie, and works with all versions of Raspian, but for what ever reason, needs a little doctoring for the current Retropie?

Strange.

Anyhow, thank yoU!

[fabian]

Update 10 Mar 2016: Crispy Doom 3.3 has been released!

Crispy Doom is a fork of Chocolate Doom that provides a higher display resolution, removes the static limits of the Doom engine and offers further optional visual, tactical and physical enhancements while remaining entirely config file, savegame, netplay and demo compatibile with the original.

Crispy Doom 3.3 is mostly a bug-fix release with only few new features.

The Good: For the first time, this release of Crispy Doom is accompanied by some kind of a "Music Pack". It contains the fluidsynth library and all the libraries that it depends on, bundled with a freely-available soundfont. In order to use this "Music Pack", download the ZIP archive, extract its content into your Crispy Doom directory, select the "Native MIDI" music device and start Crispy Doom from the crispy-doom-music-pack.bat batch file. This file sets some environment variables that are required to convince the SDL_Mixer library to use fluidsynth with the bundled soundfont for music rendering. The Music Pack is available for download here:

http://www.greffrath.com/~fabian/crispy-doom-music-pack_2.zip

The Bad: From this release on, Crispy Doom will get released without Crispy Heretic, Hexen and Strife. These three games haven't seen any serious development in the past two years and have only been carried as dead freight. This situation will not change until someone volunteers to take over active maintenance of these ports.

The Ugly: From this release on, the official Win32 binaries will be build on MSYS2. The supplemental shared libraries bundled with the release will also be taken from this distribution. Since ABI-compatibility with the libraries bundled with former releases cannot be guaranteed, it is recommended to install this release into a clean directory and not mix up the libraries with other releases. (Erratum: FLAC playback is currently broken. A pull request against the SDL_mixer package in MSYS2 has already been issued.)

Highlights of the 3.3 release include:

* Variable frame rate mode
* Support for ANIMATED and SWITCHES lumps
* Fixed nasty multiplayer bug
* etc...

Please visit the Crispy Doom homepage for more information:
http://fabiangreffrath.github.io/crispy-doom

The Crispy Doom source code is available at GitHub:
https://github.com/fabiangreffrath/crispy-doom

Binaries for Windows (x86) are available here:
http://www.greffrath.com/~fabian/crispy-doom_3.3.zip
http://www.greffrath.com/~fabian/crispy-doom-music-pack_2.zip

Have a lot of fun!

- Fabian

[plums]

If I want to build my own binary, should I switch to MSYS2? Or was it just for your own convenience?

As I said before I'd like to try to take over Crispy Heretic/Hexen some time... nobody hold their breath though.


edit: Also, yay!

[fabian]

plums said:

If I want to build my own binary, should I switch to MSYS2? Or was it just for your own convenience?

No, it's not a requirement, but a personal preference of my own. Actually, it's a well-maintaned fork of MSYS (which in turn was a fork of Cygwin focussed on light weight and portability) with great integration of MinGW-W64 (i.e. native GCC for Windows), a package management system ported over from Arch Linux with a huge repository of binary packages and a Bash shell on Windows.

As I said before I'd like to try to take over Crispy Heretic/Hexen some time... nobody hold their breath though.

Howgh! ;)

[Linguica]

fabian said:

* Variable frame rate mode

Maybe this sounds dumb, but could this be set to any arbitrary frame rate, or is 60fps support grossly hacked in somehow?

[Linguica]

Also this is weird and I don't know what would cause it, but I just realized that Crispy Doom doesn't even run at 35fps when it's at that setting anyway.

To make sure I wasn't imagining things, I tried recording my desktop at 60fps, then took a 60-frame snippet of strafing in Crispy Doom with 35fps mode on. I did it a couple times and counted the frames I got each time, and it was only 26 or 27 individual frames within that second.

I'm not sure how to show it off, but here's a 60-frame GIF showing off exactly what I got when I recorded it. If you look at it in a GIF editor you will see there are (I think) 27 unique frames within the 60, spread out kind of haphazardly.

My computer is a fairly modern desktop that runs modern games just fine, so I don't see how it could be a hardware problem.

[plums]

Out of curiosity, what does the SHOWFPS cheat report?

[Linguica]

It says 35, which isn't really surprising - I'm sure the game is running fine, there's just something going on in the game -> SDL -> OS chain that's making it drop a lot of frames.

In 60fps mode, it seems to be showing 60 fps as one would expect.

[Danfun64]

Here's an unofficial quick fix for getting stuff like flac to work.

http://www.mediafire.com/download/27c7vgel0ugsckf/crispy-doom-dlls.zip

all of these dlls come from msys2.org

edit: using cdoommus.wad in conjunction with consoledoom.wad sounds weird. The duke4 flac tracks sound normal, but looping doesn't seem to work.

[Linguica]

My first thought was to build Crispy from source and put in some fprintfs to see what's going on. I put in a SDL_GetTicks call right at the end of D_Display, and then another right after SDL_Flip, to see what might be going on. It looks like it's doing SDL_Flip 35 times a second, just as one would expect.

Spoiler

just finished normal D_Display at 2015
just did a sdl_flip at 2019
just finished normal D_Display at 2046
just did a sdl_flip at 2050
just finished normal D_Display at 2065
just did a sdl_flip at 2069
just finished normal D_Display at 2094
just did a sdl_flip at 2098
just finished normal D_Display at 2123
just did a sdl_flip at 2129
just finished normal D_Display at 2155
just did a sdl_flip at 2159
just finished normal D_Display at 2186
just did a sdl_flip at 2190
just finished normal D_Display at 2209
just did a sdl_flip at 2213
just finished normal D_Display at 2237
just did a sdl_flip at 2241
just finished normal D_Display at 2265
just did a sdl_flip at 2269
just finished normal D_Display at 2296
just did a sdl_flip at 2300
just finished normal D_Display at 2325
just did a sdl_flip at 2329
just finished normal D_Display at 2351
just did a sdl_flip at 2355
just finished normal D_Display at 2380
just did a sdl_flip at 2384
just finished normal D_Display at 2415
just did a sdl_flip at 2419
just finished normal D_Display at 2437
just did a sdl_flip at 2441
just finished normal D_Display at 2466
just did a sdl_flip at 2470
just finished normal D_Display at 2494
just did a sdl_flip at 2499
just finished normal D_Display at 2523
just did a sdl_flip at 2527
just finished normal D_Display at 2555
just did a sdl_flip at 2559
just finished normal D_Display at 2580
just did a sdl_flip at 2584
just finished normal D_Display at 2608
just did a sdl_flip at 2612
just finished normal D_Display at 2646
just did a sdl_flip at 2649
just finished normal D_Display at 2665
just did a sdl_flip at 2670
just finished normal D_Display at 2696
just did a sdl_flip at 2699
just finished normal D_Display at 2723
just did a sdl_flip at 2727
just finished normal D_Display at 2751
just did a sdl_flip at 2755
just finished normal D_Display at 2785
just did a sdl_flip at 2788
just finished normal D_Display at 2808
just did a sdl_flip at 2811
just finished normal D_Display at 2837
just did a sdl_flip at 2840
just finished normal D_Display at 2875
just did a sdl_flip at 2878
just finished normal D_Display at 2894
just did a sdl_flip at 2897
just finished normal D_Display at 2925
just did a sdl_flip at 2929
just finished normal D_Display at 2951
just did a sdl_flip at 2954
just finished normal D_Display at 2980
just did a sdl_flip at 2983

So why it doesn't actually display at 35fps on my PC, I have no idea.

edit: I just tried timing intervals between loops of d_doomloop(), is this variation normal? there should be 28 or 29 ms between each iteration of the loop, but I see anywhere from 20 to 38...

Spoiler

time since last doomloop: 30
time since last doomloop: 37
time since last doomloop: 20
time since last doomloop: 27
time since last doomloop: 28
time since last doomloop: 34
time since last doomloop: 30
time since last doomloop: 21
time since last doomloop: 28
time since last doomloop: 28
time since last doomloop: 32
time since last doomloop: 30
time since last doomloop: 23
time since last doomloop: 28
time since last doomloop: 37
time since last doomloop: 20
time since last doomloop: 30
time since last doomloop: 27
time since last doomloop: 28
time since last doomloop: 36
time since last doomloop: 20
time since last doomloop: 29
time since last doomloop: 37
time since last doomloop: 18
time since last doomloop: 32
time since last doomloop: 25
time since last doomloop: 29
time since last doomloop: 36
time since last doomloop: 21
time since last doomloop: 29
time since last doomloop: 28
time since last doomloop: 27
time since last doomloop: 33
time since last doomloop: 25
time since last doomloop: 29
time since last doomloop: 37
time since last doomloop: 30
time since last doomloop: 20
time since last doomloop: 26
time since last doomloop: 29
time since last doomloop: 33
time since last doomloop: 30
time since last doomloop: 23
time since last doomloop: 26
time since last doomloop: 28
time since last doomloop: 32
time since last doomloop: 29
time since last doomloop: 25
time since last doomloop: 27
time since last doomloop: 36
time since last doomloop: 20
time since last doomloop: 29
time since last doomloop: 27
time since last doomloop: 33
time since last doomloop: 29
time since last doomloop: 22
time since last doomloop: 28
time since last doomloop: 38

[fabian]

Linguica said:

Maybe this sounds dumb, but could this be set to any arbitrary frame rate, or is 60fps support grossly hacked in somehow?

Yes, theoretically it could be set to any frame rate you like. And, yes, it is a gross hack.

You can find all the relevant code in I_FinishUpdate() in i_video.c. In a few words, it is running at uncapped framerate, but now there is a loop in that function which makes it sleep until the 1/N of a second has passed. Only then it renders the screen again.

I have chosen 60 and 70 fps for selection in the menu because they made the most sense to me: 60 Hz is the refresh rate of most modern screens and 70 fps is the exact double original rendering rate. I hope to replace this hack with proper VSync one the code base has switched to SDL2.

Regarding you other findings, I find them very puzzling. My first guess is the coarseness of the sleep() function. By spec, e.g. sleep(1) asks the OS to sleep *at least* for 1ms, so it may be possible that the OS returns to the process after as much as, say, 20ms. If this sums up, you inevitably won't be able to keep the frame rate constant.

[vadrig4r]

fabian said:

No, it's not a requirement, but a personal preference of my own. Actually, it's a well-maintaned fork of MSYS (which in turn was a fork of Cygwin focussed on light weight and portability) with great integration of MinGW-W64 (i.e. native GCC for Windows), a package management system ported over from Arch Linux with a huge repository of binary packages and a Bash shell on Windows.

Howgh! ;)

Funny, I just came across MSYS2 myself and started using it when I saw it integrates pacman which I was already familiar with. Congrats on 3.3!

[dugan]

I'm in the middle of Alien Vendetta with Crispy DOOM 3.2. Is 3.3 savegame-compatible with 3.2?

[fabian]

dugan said:

I'm in the middle of Alien Vendetta with Crispy DOOM 3.2. Is 3.3 savegame-compatible with 3.2?

Yes, it is just as savegame compatible to Vanilla Doom 1.9 as Chocolate Doom is.

[fabian]

fabian said:

Regarding you other findings, I find them very puzzling. My first guess is the coarseness of the sleep() function. By spec, e.g. sleep(1) asks the OS to sleep *at least* for 1ms, so it may be possible that the OS returns to the process after as much as, say, 20ms. If this sums up, you inevitably won't be able to keep the frame rate constant.

Seems like I wasn't too far off with my assumption: http://devcry.heiho.net/html/2015/20150211-rock-solid-frame-rates.html

Also, Zodomaniac has found some bugs in my Music Pack: There is a typo in the batch file and at least one library is missing for Ogg Vorbis playback. I will release a new one once the SDL_Mixer library is capable of FLAC playback.

[Linguica]

I'm not so sure that the SDL sleep function is the culprit. I tried compiling with frame rate set to 30, which I've thought in the past might be an interesting solution to choppy frame times. I was kind of shocked to see that it Just Worked, except the controls felt kind of sluggish, which is probably not unexpected.

I tried doing the video capture thing again, and it was clear that the frame rate was MUCH more stable - I made a 60fps 1 second GIF again, and except for a couple hitches, each frame came exact 2 frames after the last, instead of jumping around like at 35fps.