fabiangreffrath / crispy-doom

Crispy Doom is a limit-removing enhanced-resolution Doom source port based on Chocolate Doom.

Crispy Doom

Crispy Doom is a limit-removing enhanced-resolution Doom source port based on Chocolate Doom.

Its name means that its internal 640x400 resolution looks "crisp" and is also a slight reference to its origin.

Synopsis

Crispy Doom is a friendly 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 compatible with the original.

Objectives and features

Crispy Doom is a source port that aims to provide a faithful Doom gaming experience while also featuring some user-requested improvements and enhancements. It is forked off of Chocolate Doom to take advantage of its free and open-source code base, portability, accuracy and compatibility with Vanilla Doom.

Its core features are:

• Enhanced 640x400 display resolution, with the original 320x200 resolution still available in the "High Resolution Rendering: Off" mode.
• Widescreen rendering for using all the available horizontal space of screens with aspect ratios up to 24:9.
• Uncapped rendering framerate with interpolation and optional vertical synchronization (VSync) with the screen refresh rate.
• Intermediate gamma correction levels (0.5, 1.5, 2.5 and 3.5).
• Removal of all static engine limits, or at least raising of the less crucial ones.
• Full support for the "Doom Classic" WADs shipped with the "Doom 3: BFG Edition", especially the "No Rest For The Living" episode shipped in the NERVE.WAD file.
• Support for all versions of John Romero's Episode 5: Sigil for Ultimate Doom.

Furthermore, the following optional user-visible and audible features are available:

• Jumping.
• Free vertical looking, including mouse look and vertical aiming.
• Aiming support by a crosshair that may get directly rendered into the game world.
• A new minimal Crispy HUD, displaying only the status bar numbers.
• Clean Screenshot feature, enabling to take screenshots without HUD elements and even without status bar numbers and weapon sprites at higher screen sizes.
• Colorized status bar numbers, HUD texts and blood sprites for certain monsters.
• Translucency for certain sprites and status bar elements in the Crispy HUD.
• Randomly mirrored death animations and corpse sprites.
• Command line options to allow for playing with flipped player weapon sprites and/or entirely flipped level geometry.
• Players may walk over or under monsters and hanging corpses.
• Centered Weapons when firing, weapon recoil thrust and pitch.
• Reports whenever a secret is revealed.
• Level statistics and extended coloring in the Automap.
• Playing sounds in full length, and misc. other sound fixes.
• Demo recording and/or playback timers and progress bar.
• Demo continue, fast-forward and take-over features, handing controls over to the player when demo playback is finished or interrupted.

Most of these features are disabled by default and need to get enabled either in the in-game "Crispness" menu, in the crispy-doom-setup tool or as command line parameters. They are implemented in a way that preserves demo-compatibility with Vanilla Doom and network game compatibility with Chocolate Doom. Furthermore, Crispy Doom's savegames and config files are compatible, though not identical (see the Compatibility section in the Wiki, to Vanilla Doom's.

Crispy Doom strives for maximum compatibility with all "limit-removing Vanilla" maps -- but not Boom or ZDoom maps. More specifically, Crispy Doom supports some select advanced features such as ANIMATED and SWITCHES lumps, MBF sky transfers, SMMU swirling flats and MUSINFO -- but neither generalized linedef and sector types nor DECORATE and MAPINFO.

Many additional less user-visible features have been implemented, e.g. fixed engine limitations and crashes, fixed rendering bugs, fixed harmless game logic bugs, full support for DEHACKED files and lumps in BEX format, additional and improved cheat codes, an improved Automap, and many more! Due to the extra DEHACKED states added from MBF, Crispy Doom supports enhancer mods that can make the gameplay even more pleasing to the eyes. For a detailed list of features and changes please refer to the release notes below.

Download

• Windows: Get binaries of the latest release, compatible with both x86 and x64 editions.
• MacOS: Use MacPorts: sudo port install crispy-doom or Homebrew: brew install crispy-doom.
• Linux: To install on Ubuntu (“Eoan Ermine” 19.10 and later)/Debian (“Buster” 10 and later) based systems: sudo apt-get install crispy-doom

The most recent list of changes can be found in the Changelog. A complete history of changes and releases can be found in the Wiki or on the Releases page.

Daily builds of Crispy Doom can be found here: http://latest.chocolate-doom.org/

Crispy Doom can play nearly all variants of Doom. If you don't own any, you may download the Shareware version of Doom, extract it and copy the DOOM1.WAD file into your Crispy Doom directory. Alternatively, you may want to play Crispy Doom with Freedoom and a MegaWAD.

Sources

The Crispy Doom source code is available at GitHub: https://github.com/fabiangreffrath/crispy-doom. It can be downloaded in either ZIP or TAR.GZ format or cloned via

 git clone https://github.com/fabiangreffrath/crispy-doom.git

• Brief instructions to set up a build system on Windows can be found in the Crispy Doom Wiki. A much more detailed guide is provided in the Chocolate Doom Wiki, but applies to Crispy Doom as well for most parts.
• There are also instructions for building on Linux and MacOS

Documentation

• New Cheat Codes
• New Command-Line Parameters
• New Controls (With default bindings)
• Crispness
• Compatibility
• FAQ

Contact

The canonical homepage for Crispy Doom is https://github.com/fabiangreffrath/crispy-doom

Crispy Doom is maintained by Fabian Greffrath.

Please report any bugs, glitches or crashes that you encounter to the GitHub Issue Tracker.

Acknowledgement

Although I have played the thought of hacking on Chocolate Doom's renderer for quite some time already, it was Brad Harding's Doom Retro that provided the incentive to finally do it. However, his fork aims at a different direction and I did not take a single line of code from it. Lee Killough's MBF was studied and used to debug the code, especially in the form of Team Eternity's WinMBF source port, which made it easier to compile and run on my machine. And of course there is fraggle's Chocolate Doom with its exceptionally clean and legible source code. Please let me take this opportunity to appreciate all these authors for their work!

Also, thanks to plums of the Doomworld forums for beta testing, "release manager" SoDOOManiac and "art director" JNechaevsky for the continuous flow of support and inspiration during the post-3.x development cycle and (last but not the least) Cacodemon9000 for his Infested Outpost map that helped to track down quite a few bugs!

Furthermore, thanks to VGA for his aid with adding support for his two mods: PerK & NightFright's Black Ops smooth weapons add-on converted to DEHACKED and Gifty's Smooth Doom smooth monster animations converted to DEHACKED that can make the gameplay even more pleasing to the eyes.

Legalese

Doom is © 1993-1996 Id Software, Inc.; Boom 2.02 is © 1999 id Software, Chi Hoang, Lee Killough, Jim Flynn, Rand Phares, Ty Halderman; PrBoom+ is © 1999 id Software, Chi Hoang, Lee Killough, Jim Flynn, Rand Phares, Ty Halderman, © 1999-2000 Jess Haas, Nicolas Kalkhof, Colin Phipps, Florian Schulze, © 2005-2006 Florian Schulze, Colin Phipps, Neil Stevens, Andrey Budko; Chocolate Doom is © 1993-1996 Id Software, Inc., © 2005 Simon Howard; Chocolate Hexen is © 1993-1996 Id Software, Inc., © 1993-2008 Raven Software, © 2008 Simon Howard; Strawberry Doom is © 1993-1996 Id Software, Inc., © 2005 Simon Howard, © 2008-2010 GhostlyDeath; Crispy Doom is additionally © 2014-2019 Fabian Greffrath; all of the above are released under the GPL-2+.

SDL 2.0, SDL_mixer 2.0 and SDL_net 2.0 are © 1997-2016 Sam Lantinga and are released under the zlib license.

Secret Rabbit Code (libsamplerate) is © 2002-2011 Erik de Castro Lopo and is released under the GPL-2+. Libpng is © 1998-2014 Glenn Randers-Pehrson, © 1996-1997 Andreas Dilger, © 1995-1996 Guy Eric Schalnat, Group 42, Inc. and is released under the libpng license. Zlib is © 1995-2013 Jean-loup Gailly and Mark Adler and is released under the zlib license.

The Crispy Doom icon (as shown at the top of this page) has been contributed by Philip K.

crispy-doom's Issues

Option to ignore cheat code changes in dehacked patches

You can change the cheat code strings in dehacked. This is annoying, especially if you're trying to bug-test a map. It would be nice if these string changes could be ignored, or if the normal Doom ones were hard-coded to also work, or something.

Small glitches on weapon when standing still and screen size is bordered

reported by Cyanosis on DW: http://www.doomworld.com/vb/post/1258257

By bordered screen, he means screenblocks <= 9, i.e. reducing the screensize smaller than just having the statusbar. Easiest to notice on the pistol when screenblocks = 9, just move slightly and you can see a few orange pixels flicker off and on on the pistol.

Don't crash in options screen with a high sensitivity

As per Vanilla Doom, Chocolate crashes in the options screen when the mouse sensitivity is too high past what you can set in game (9?). I think it would be nice if Crispy could handle larger values. Ideally you could set larger values in game from the options screen (perhaps not as high as 256, which is the max in crispy-doom-setup), but even just not crashing would be nice.

Allow quickload before quicksave

Pressing quickload when you don't have a quicksave slot gives you a message like "you haven't picked a quicksave slot yet!" or something to that effect. Would be better to just bring up the load game menu and have the spot you pick become the quicksave slot, assuming a valid save game is loaded.

Also, does the quicksave slot get cleared ever, apart from quitting? Might be nice to allow that, though I'm not entirely sure how would be best.

Create new key_alt_* key functions, and untie the menu keys from player movement

Just a reminder :)

Bad V_DrawPatch crash when text strings are too long for the screen

As reported by Dragonsbretheren at http://www.doomworld.com/vb/post/1301855

An easier test case is with the HacX 1.2 iwad: start a game and type SEEIT (or IDBEHOLD is using -nocheats).

Extended demos in other Crispy games, and Chocolate compatibility

Now that I am set up to play around with the Crispy/Chocolate source and work with git, one of the first things I'd like to try to do is to add extended demo support to Heretic/Hexen/Strife. Things like unlimited demo length, support for -longtics, multi-level movies, etc.

I'm going to ask fraggle if he thinks that any of these things belong in Chocolate Doom. I think there is enough precedent for it, but it's up to him. If he doesn't, then I'd like to include them in the Crispy Doom package. But, this will mean that Crispy Heretic/Hexen/Strife could produce demos that the Chocolate games couldn't play, if certain options like -longtics are used.

Does this go against your goals for Crispy Doom? Of course, Chocolate demos will still play in Crispy, and extended demos from Crispy will also play in other DOS programs (vv Heretic and Hexen-plus).

I'll post a full list of what I'd like to change on the Chocolate Doom tracker, in a bit. I want to play with Strife first since I know nothing about demo recording for it.

Functions and global variables should always be made static if possible.

chocolate-doom/HACKING tells "Functions and global variables should always be made
static if possible." I should review all the code changes I made and obey to this rule.

Also, I should avoid unconditional writes, like many of the "dp_translation = NULL" calls I introduced.

Moving sectors can cause monsters to get stuck in (or on top of) the player

With things over things of course. Here is an example file:

https://www.mediafire.com/?bcz61d5ffid37ek

Shoot, and then walk forward. The pain elemental will likely get stuck in you. Similarly, lowering the lift while under the imp will cause him to drop on (and in) you immediately.

I don't know if moving ceilings can ever cause this, I imagine they might with flying monsters.

One thing I encountered while playing NOVA, that I cannot seem to replicate, is a situation like the imp on the platform, except lowering it caused the monster to hang in mid-air. Seems like a pretty rare occurrence though.

That is all the issues I have for Crispy Doom currently! There is one more problem with Dehacked patches but I imagine this stems from Chocolate Doom.

Lost souls spawned by pain elementals still bleed blood, instead of puffs

Lost souls from either the attack or death of a pain elemental still bleed red blood.

Doom 2 MAP09 is a good test case, turn 90 degrees left and take the lift, there will be a pain elemental at the top. In that area there is a lion face switch that is a door, that will eventually lead to a normal lost soul.

Crash from setup when trying to test settings

In the setup program, going into the mouse, keyboard, or joystick settings, you can press 'T' to test your settings. In Crispy Doom 1.1 this causes a crash. It worked fine in the first Crispy 1.1 beta, don't know about the 2nd, and it works fine in the latest Chocolate Doom devbuild. Using the win32 build.

running crispy doom leaves a file "C:\tranmap.dat"

On Win32, I get a tranmap.dat file in the root of my c: drive every time I run Crispy Doom. Harmless, but it shouldn't be there.

flac and ogg vorbis support

Congrats on the new release! I notice that the Windows builds are built without support for flac or ogg music. Have you tried building these? I have not had luck with flac on Windows at all, but ogg support was relatively painless.

Crispy needs a new icon

I think it's definitely it's own thing rather than just a Chocolate Doom patch, so it shouldn't use the Chocolate Doom icon. Any ideas? I don't know if you can get a chocolate crispy dessert into a 32px icon and still have it recognizable.

Don't display rude beta quit messages when playing chex quest

While I appreciate the humour in playing a non-violent kids game, only to be told "Fuck you, pussy! Get the fuck out!" when trying to quit, it seems like it should maybe be omitted.

Chocolate already has a special case for -iwad chex.wad that sets some other parameters, I think.

Fix tutti-frutti for transparent textures

Since you've already fixed TF from short textures, and medusa from multi-patch textures, I think it would make sense to fix this too. Transparent textures used as an upper or lower texture, or on a 1-sided wall as a mid texture, produce visual glitches from undefined results.

The "usual" way that other ports handle this is to replace the transparency with black, though this isn't exactly standard - even PrBoom+ looks a bit glitchy in software mode.

example file: https://www.mediafire.com/?spsnd055tk59txm

targets not preserved in saved games

Note to myself: There must be a way to preserve targets in savegames without breaking Vanilla compatibility.

Back to the Roots

I have the feeling that I have recently lost focus in the development of Crispy Doom. It was intended as "Vanilla with Vanilla-compatible enhancements". However, many Vanilla-incompatible features have been added recently and "if (singleplayer)" is scattered all over the code. I am considering to remove most of these features again and follow some kind of "feature policy":

Features should be user-visible (and drastic, but that's subjective) and must be Vanilla-compatible (with stretches, e.g. weapon sprite centering). If they are not Vanilla-compatible, they must be switchable (e.g. vertical aiming, jumping, recoil). If a feature is Vanilla-incompatible, but doesn't "deserve" a dedicated switch, it gets kicked.

Unfortunately, this will kick out neat features like SSG gibbs or chainsaw/fist switching. On the other hand, most of these have either been merged into Doom Retro already or even taken from there. Altogether, I believe Doom Retro already fills the "Vanilla with Vanilla-incompatible enhancements" niche quite well.

Thoughts?

Mirrored death animation & corpses

Doom Retro has a feature whereby killing an enemy will display the death animation mirrored horizontally 50% of the time. I thought it was a really nice feature, it adds a lot for something so simple.

Rise sprites limits

Monsters in NUTS.WAD still flickers due to a limit regarding number of sprites showing on the screen simultaneously. Maybe the limits should be risen a bit?

http://www.doomworld.com/idgames/index.php?file=levels/doom2/Ports/m-o/nuts.zip

Coloured blood, and HacX (and other mods)

So one thing about coloured blood is that if you're playing a conversion that replaces all the enemies, the blood colour won't always match. This wasn't such a huge deal in original Doom, where everything bled red anyhow, and modders could choose to make things bleed puffs with Dehacked. But for certain mods it might look weird if humans bleed green or blue blood.

I don't know the best way to handle this; maybe check for replacement sprites and/or dehacked modifications to things, and change the blood back to red as needed?

HacX is a bit different, in that it's sort of a standalone game even though it's playable like any other wad in Chocolate Doom. I think most of the monsters either bleed red, or are mechanical and just get puffs through Dehacked, but there's at least one creature that has green blood. Is it worth making a special case for it?

Not sure about Chex Quest, about to try it out...
edit: Of course, Chex Quest already has green "slime" instead of blood, so no problems there.

Prevent overwriting files when recording demos

More demo stuff. I don't know if this is even something that belongs in a Doom port. All other ports will happily overwrite files when recording demos, for better or worse.

Support for embedded ogg/flac music (eventually)

Once chocolate doom gets flac and ogg sorted out a bit more, what do you think of being able to play such formats when they're lumps inside wads?

I guess it should be an optional feature for *NIX builds, and give an error message and play silence instead of crashing when trying to play those filetypes if they're not supported.

Centre automap markers on the map

Vanilla behaviour is to place the automap marker down and to the right of the player (or map centre when follow mode is off). It would be nicer if it were placed right in the centre.

Make issue

We seem to have a make rule called that doesn't exist. I've done some digging and I'm still confused on how this rule is being called. Seems to be a dynamically generated rule.

So hear is the make error:
make[2]: *** No rule to make target crispy-server.6', needed byall-am'. Stop.

all-am says this:
all-am: Makefile $(DATA) config.h

The only reference to crispy-server I can find is that it is a binary file in our source directory. Possibly if the 6 was removed this rule would successfully execute.

I'm a little confused how the 6 got there to be honest.

Separate horizontal and vertical mouse sensitivity / reduce mouselook sensitivity

Especially now that there is mouselook, it would be nice to be able to have vertical sensitivity separate from horizontal. Right now the only way to do this is with acceleration, which isn't a great solution.

Maybe the problem is just too high sensitivity for mouselook. Right now I have my mouse speed at 38, which is what I like for turning left and right but is way too high for looking up and down. Having the speed down all the way to 1 feels right for up/down looking, even then it's a bit high.

Using 32 bit windows, in case that matters.

PrBoom+ compatibility with mouselook in demos

You probably know that PrBoom+ records mouselook in demos when it is used, in a way that makes the demo still compatible with other ports that don't use mouselook (assuming an appropriate wad and complevel setting). Since Crispy Doom now features mouselook, it would be cool if it could deal with mouselook in demos in a compatible way. Exact angles shouldn't be necessary (GLBoom+ allows for vertical mouselook across 180 degrees) since it doesn't affect gameplay.

Weapons drawn 1 pixel too high when player is idle

When the player is stationary, their weapon is drawn 1 pixel higher than when they are moving. You can notice if you tap forward briefly and pay attention to the weapon sprite as you glide to a stop. With some weapons such as the pistol and shotgun, and the screen size at max (i.e. no status bar), there is a 1px gap between the bottom of the screen and the weapon, through which you can see the floor texture or whatever else is there. (This is basically the only reason to report this bug.)

I think the weapon firing sprites are also drawn too high, at least sometimes. I can notice the 1px gap when firing the pistol.

Seems to affect all games, and not depend on the video settings at all.

Palette changes cause visual errors with transparency

Don't know if there's a good way to handle this, but if a wad changes its PLAYPAL lump this can potentially make transparent sprites look weird. I noticed it when playing D2TWID which redefines palette indexes 250 and 255 as cyan, for its custom sprites.

Maybe simply avoiding using those colours would work, as I don't think any stock Doom/Doom 2 graphics use them. (They're only used in the COLORMAP.)

Obviously the player can disable transparency if things look too bad, so I wouldn't call this a critical problem.

Any reason to use -file over -merge?

Makes sense for Chocolate Doom, since it's trying to preserve compatibility errors, but for Crispy Doom I don't see why one would ever need to use -file instead of -merge. So I propose that -file just does the same thing as -merge does.

Some wads might only work with -aa or -nwtmerge but those can be left in.

R_MapPlane error

Hi fabian, can you have a look at this map and demo with the current git revision of Crispy Doom? Loaded with crispy-doom.exe -iwad doom.wad -file INVASION.WAD; the deh doesn't matter in this case.

http://www.doomworld.com/idgames/index.php?file=levels/doom/megawads/inva_19.zip

http://www.mediafire.com/download/czsya945a448shn/invasion_mapplane.lmp

The demo was recorded with Crispy 1.5, for which it behaves fine. In the current git, I'm getting an R_MapPlane error consistently at the same spot. Sometimes there are graphical glitches there instead of a crash.

Could be related to the FRACUNIT fix?

Transparent numbers in Crispy HUD

I'll be honest, I just like transparency on anything that might work with it. Anyhow, transparency on the HUD numbers, at least the ammo/health/armour ones, might look nice?

Don't desync when entering menus while recording demos

When recording a demo, pressing Escape or any other key that opens a menu will lead to the demo desyncing at that point. It would be nice if that didn't happen. PrBoom+ pauses the demo transparently (i.e. the pause is not recorded in the demo), but even just leaving the game running like in multiplayer would be fine.

Correct "sky never changes" bug

http://doomwiki.org/wiki/Sky_never_changes_in_Doom_II

Was actually fixed in the source code release of linuxdoom, but Chocolate Doom re-breaks it intentionally, to be more like vanilla.

The fix in linuxdoom is this, in G_DoLoadLevel of g_game.c. I guess it needs to support dehacked replacements for the SKYx strings like in G_InitNew?

    skyflatnum = R_FlatNumForName ( SKYFLATNAME ); // this line is in choco

    // DOOM determines the sky texture to be used
    // depending on the current episode, and the game version.
    if ( (gamemode == commercial)
     || ( gamemode == pack_tnt )
     || ( gamemode == pack_plut ) )
    {
    skytexture = R_TextureNumForName ("SKY3");
    if (gamemap < 12)
        skytexture = R_TextureNumForName ("SKY1");
    else
        if (gamemap < 21)
        skytexture = R_TextureNumForName ("SKY2");
    }

    levelstarttic = gametic;        // for time calculation  // this line is in choco

Statusbar face sometimes visible when using noclip

Very minor, maybe not even worth fixing depending on how you're drawing the HUD. But a bug nonetheless.

• Start a new game on E1M1
• Press + until the screensize is maxed and the HUD is displayed
• Turn left about 45 degrees, so you face the tech light
• Select the fists
• Turn on noclip
• Run backwards. Shortly after you drop, you will see Doomguy's face.
• While still there, press a menu key. The whole statusbar appears.

BEX format parsing and long-strings support

Since it's clear that fraggle is not interested in BEX support for Chocolate Doom, should it go in Crispy?

It would also be good to allow for long strings in the normal Dehcaked format. i.e.

Text 17 52
level 1: entrywaylevel 1: my super cool MAP01 replacement is the best

will get rejected for being too long. IIRC long strings are already enabled for Chex Quest.

There are a few things that BEX can do that Dehacked cannot; in Dehacked only frames with a codepointer can be replaced by another codepointer (and must have some codepointer attached), whereas with Boom this doesn't matter.

Also, regarding the D2TWID.deh patch we discussed in the Chocolate Doom tracker: I'm pretty sure that that is a fully-BEXed patch, because there is no other way to express some of those changes in Boom-format, at least according to https://github.com/fragglet/mbf/blob/master/boomdeh.txt. For instance BEX defines blocks for [CODEPTR] and [STRINGS], but there is no equivalent [FRAMES] section, so you are limited to the Dehacked way (with Boom mnemonics for flags, optionally.) Also not every replacement string is accessible in [STRINGS].

Allow things over things?

Here's a drastic one: allow things to move over/under other things, like in other Doom-based games. Single-player only of course.

One issue is that a lot of decorations have a height of 16 by default, and would need to have their height increased appropriately. This in turn makes them stop projectiles.

Quick 180-degree turn keyboard key

For those holdouts that still use only the keyboard (I am not one of them), a 180 degree turn key might be nice. PrBoom+ and Eternity both have one, not sure of other ports.

Option to turn off extra leaving messages (CONTAINING PROFANITY!).

While some like this option, I think it would be nice to have the option to turn it off.

Requests for Crispy Doom

Hello, I have been told to register here to ask requests. My requests are:

1. Restore the "weapon centering" behavior introduced in version 1.5 back to Vanilla Doom. I will be honest when I say that but this minor change bothers me a lot since this isn't supposed to be ZDoom (ZDoom was first source port to adapt this feature) and while I got used to it, I don't think this belongs to Crispy Doom. Sure, you can make it optional and still have the old behavior back by adding "weapon centering" option into crispiness menu and not forcing it down our throat. This is one of the features I always loved at vanilla/chocolate Doom, that how weapon freezes in the same spot you are shooting. But after the "disappointing" 1.5 update, weapon ALWAYS goes to the center. I seriously don't like this and would be better as an optional feature for those who prefer the new behavior.

2. Colored Numbers on HUD. I have seen a recent discussion here about making the HUD numbers compatible with wads that change the font and color. The only suggestion I can give here is to look into ZDoom's alternate HUD code since it seems to be compatible with all fonts.

3. Master Levels support. We all want an "official" way to play Master Levels complete with automap/end screen names, par times, skies, music, etc. all while done in vanilla style. I have 2 solutions for this:

a. Either make a DOS-like interface, so you can select Master Levels in same way as Doom-It does

b. Or add "Master Levels" as a second episode in the main menu when Crispy Doom detects the directory for Master Levels. Since No Rest For The Living is fully supported, why not have Master Levels supported too? Assuming you have both expansions installed, the episode selection menu should now look like:

Hell On Earth
Master Levels
No Rest For The Living

However that way Master Levels will have to be combined and rearranged into an episode which would break the balance of maps. And yes I am aware that they are fully supported by other source ports such as Eternity (with native support for the expansions), as well as ZDoom (by using a mod called Master Levels Menu Interface or by using an unofficial patch provided on Blzut3's website) but having the master levels supported in Crispy Doom would be nice.

Thank you for reading.
-FistMarine

crashes with IDMUS

IDMUS00 in Doom 2 will attempt to play D_INTROA . If that music lump is not found, the game crashes.

IDMUS0x or IDMUS10 in Ultimate Doom will crash with a "bad music number" error.

In both cases it would be better to display the "Impossible Selection" text instead (STSTR_NOMUS), as is done when you try to switch to a too-high music number.

Make weapon firing sprites translucent?

3DGE does this and I think it looks pretty good. The "muzzle flash" sprites are a separate sprite from the weapons, so it shouldn't be too hard (?) to make only those translucent. Probably best to do it dynamically, in case of weapon mods, but if you want a list of sprites here they are:

PISFA
SHTFA
SHTFB
CHGFA
CHGFB
MISFA
MISFB
MISFC
MISFD
PLSFA
PLSFB
BFGFA
BFGFB
SHT2I
SHT2J

Game crashes when player is in sector with unknown type

If the player enters a sector with an invalid/unknown sector type, Crispy Doom will crash. Normally a proper level should not have these problems, but it can still happen in maps, especially with improper use of linedefs that change sector specials. Would be nice if the unknown type were simply ignored instead.

Here is a demo file if you want, crashes as soon as the player lands in the skull-textured sector.
http://www.mediafire.com/download/sjk8ntir2nckcu1/unknown_sector_type.wad

As far as I can tell, unknown linedef types do not cause problems.

Colourize status bar numbers with Crispy HUD

If "show colored numbers in status bar" is enabled, but a pwad replaces those numbers with non-red ones, they won't get coloured. If that option is enabled and the Crispy HUD is showing, you could colourize the graphics for those numbers to red first.

It might look bad for some graphics, the question is if it's too annoying to toggle the coloured numbers option in setup back and forth. Also I suggest not colourizing with the normal statusbar since custom statusbar numbers often compliment a custom statusbar as well.

A simple "colourize to red" formula is new_r = min(r,g,b) + max(r,g,b) capping at 255, new_b = new_g = 0 .

Support for extended nodes

A "risky" request as you might say: support ZDBSP (and maybe DeePSea) extended nodes, to allow gigantic maps like in http://www.doomworld.com/vb/post/1301335 to be played. (ignore that that wad has other problems...)

Info about ZDoom's nodes are at http://zdoom.org/wiki/Node#ZDoom_extended_nodes. Don't know about DeepSea but I'm sure there are details somewhere. I know PrBoom+ supports both kinds of extended nodes as long as they're uncompressed.

Extend to other resolutions

I'm not talking about field of view nor screen scaling (as it happens in chocolate-doom), just support for more resolutions. User should have the option to keep the game's aspect ratio (resulting in black bars on the sides) or just stretch it to the whole screen.

Disable translucency on pwad replacement sprites

Or at least the powerups. I think projectiles are maybe safe to have always translucent?

It might be nice if sprite translucency (and coloured blood) were turned off on a per-sprite basis instead of turning it all of if there is one replacement sprite. A bonus is that this would also let people turn off coloured blood for individual enemies (like the latest post in the DW thread) with a simple hack of including a pwad that had the necessary sprites.

Fix spawn spots in save games errors

Related to the issue of targets not preserved in saved games is this set of bugs:
http://doomwiki.org/wiki/Spawn_spots_not_preserved_in_saved_games

1." Doom automatically generates a list of all spawn spots for any final bosses present at the beginning of each map, but it neglects to do this again when loading a saved game."
2. "In addition, if there are any spawn cubes currently in flight, the game will crash due to the fact that the cube's target field is used to track the spot at which it will spawn a monster, and targets are not recorded in saved games."
3. "When normally awakened, the cube spitter counts and stores the number of spawn spots in a variable called numtargets. When loading a saved game, this variable is not checked for consistency, and will just keep whatever value it had."

Seems like 1 and 3 should hopefully not be too hard to fix. 2 is more difficult but it depends on if and how you can fix the targets in savegames bug. As a hack, you could just delete any in-flight cubes when loading a game.

Automap marker shakes when moving

When a spot is marked on the automap by pressing M, moving while the map is displayed causes the marker number to vibrate a bit, especially if the player is moving along both axes.

Be more lenient with view centring using mouse button

See what happens when I take notes while playing? ;P

I have the RMB bound to Free Look, and I find that I have to be very careful not to move the mouse at all if I want to centre the view when pressing it. I think always centring if the button is pressed for a very short time might be nice? That or allowing a small range of movement when Free Look is pressed to still centre the view.

This kind of change might benefit from testing, so maybe you want to release 1.5 first. (Same goes for all other issues, really.)