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

Crispy Doom 5.10.3 (Update: Aug 17, 2021)

Recommended Posts

2 hours ago, fabian said:

 

Never heard of this. 

 

extras.wad is included in the 2019 release

MD5: 38e1bb6cdd1e4227eef13d22f6e35209

SHA-1: 0f2a7139b640e19a08f384562f907cb0734b0512

 

It includes some sprites which are displayed on the map.

 

map.png.ac4cda2cb49925f0c533c75bbc7dbd93.png

 

It also includes pictures of weapons which are displayed when you use weapon up or down.

 

weapons.png.7f04d4341065a849371c1c3da031bead.png

 

Lastly, it contains an audio file called DSSECRET.  I assume they were going to use this as the sound played when a secret is found, but it doesn't look like that was implemented.  They might be using it elsewhere, but I haven't played it enough to know where.

Share this post


Link to post

There's a visual glitch on Crispy Heretic 5.8.0 where when you load a game, you'll highlight the first item, but the icon shows the item when you make the save, with the number of your first item.

 

Example:

Inventory: Flask * 4, Tome, Urn

If I make the save while highlighting the Urn, and load the game, you'll see Urn * 4 in the inventory. If you use it, however, you'll consume a flask and it will turn back to the flask icon with a 3.

 

I verified this doesn't exist in Dos. In Dos, if you make a save in this case, you'll see the Flask * 4 correctly.

 

@plums <- a tag which in case you want to fix it.

Share this post


Link to post
3 hours ago, buvk said:

Lastly, it contains an audio file called DSSECRET.  I assume they were going to use this as the sound played when a secret is found, but it doesn't look like that was implemented.  They might be using it elsewhere, but I haven't played it enough to know where.

That's really interesting. Has it been ripped at all? Curious as to what it sounds like, given how I'm so used to the secret sound effect most sourceports use at this point.

Share this post


Link to post
11 hours ago, fabian said:

I have some code ready that could load all of the 20 separate Master Levels PWADs and arrange the levels internally as if they were from the single masterlevels.wad file. Would you guys be interested in this? 

If you decide to do that, could you also set things up so that not only are all the Master Levels loaded, but all of the extra levels that make up Master Levels Plus, along with Master Levels Plus's episode selections?

Also, how will this effect demo recording or multiplayer?

Share this post


Link to post

For those who prefer 4:3, have you ever thought of implementing "backgrounds" similar to what the newest official port does.

 

 

Maybe have it customizable, like having different intermission screens, having flat textures, or even a picture we can upload?

 

I like the sidebar background thing, and I think it'd be super neat to be added into the port.

image.png

Share this post


Link to post

I noticed the Restart level/demo and Go to Next Level commands don't work in Crispy Heretic. The former command would be especially nice for quick wand starts during a casual playthrough, especially if it works on Black Plague too!

Share this post


Link to post
19 hours ago, buvk said:

extras.wad is included in the 2019 release

MD5: 38e1bb6cdd1e4227eef13d22f6e35209 

SHA-1: 0f2a7139b640e19a08f384562f907cb0734b0512 

Could you provide the exact size in byte and the CRC-32 checksum, too? Thanks. :)

 

Oh, and lump count, too. Just trying to fill the wiki page up to the standard of the others.

 

Edit: nevermind, I've received the info I wanted by PM. Thanks anyway!

Edited by Gez

Share this post


Link to post
14 hours ago, Dwars said:

I noticed the Restart level/demo and Go to Next Level commands don't work in Crispy Heretic. The former command would be especially nice for quick wand starts during a casual playthrough, especially if it works on Black Plague too!

Funny, didn't notice you can set these keys before you mentioned it. I thought restarting a level with a key is a PrBoom+ thing only. It would be nice to have these for sure.

Share this post


Link to post

What do you guys think about how Crispy Doom compares to dos version and to Prboom+? Especially in terms of lighting.

 

I'm not really a fan of vanilla but I played Doom 2 on Steam for a few minutes and then Crispy Doom and the former was a bit nicer to play but I can't put my finger on why.

 

 

Share this post


Link to post
4 minutes ago, <<Rewind said:

What do you guys think about how Crispy Doom compares to dos version and to Prboom+? Especially in terms of lighting.

 

I'm not really a fan of vanilla but I played Doom 2 on Steam for a few minutes and then Crispy Doom and the former was a bit nicer to play but I can't put my finger on why.

 

You probably like the classic "chunky" feel of 320x200 + 35fps.

Share this post


Link to post

I actually just want to praise this new (for me) option which is Crispy's brightmaps for items/textures, something that suddenly opened a door for enhancing playthroughs of wads that are mostly iwad-ish with simplistic use of stock textures, so that I can focus on shiny walls :D. Even made a silly album of silly screenshots that I took recently, but they look much better in-game trust me.

 

Now my next concern is if this option is demo-friendly and also if pr/glboom+ supports a similar setting, meaning that I could record in crispy and use prb+ for video convertion. I gotta check that. 

Share this post


Link to post
13 hours ago, galileo31dos01 said:

Now my next concern is if this option is demo-friendly and also if pr/glboom+ supports a similar setting, meaning that I could record in crispy and use prb+ for video convertion.

Brightmaps don't affect demos at all. I don't think PrB+ supports anything like them, though maybe GLB can with some GLDefs settings. I'm guessing you want PrB+ because of -viddump?

Share this post


Link to post

Any chance for a pistol start option? I know there are mods for this but all are incompatible with Crispy Doom.

Share this post


Link to post

@Zaratul Might be nice. In the meantime, IDCLEV00 will restart the current level from pistol start. Or just blow yourself up with a rocket launcher :)

Share this post


Link to post

Playing Doom 2 the way ID did and on map 8 pain elementals are not shooting lost souls. I checked other ports and this bug is only present with Crispy Doom.
Checked pain elementals in vanilla D2, spawn mechanic worked, really wierd.

Share this post


Link to post

@Zaratul there are already 30+ lost souls on that map, and in vanilla engine PE won't spawn any more LS if there are already 20 or more of them. most other sourceports removed that limit.

Share this post


Link to post

Interesting, didnt know about that. Hopefully Crispy Doom gets an option to turn this off someday.

Share this post


Link to post
2 hours ago, plums said:

I'm guessing you want PrB+ because of -viddump?

 

Exactly yeah. The problem in my case is that videos sometimes glitch if I have opengl on for conversion, instead of "32 bit", so for me it's software mode or nothing until I figure out a solution, if there is one to begin with. Just looked at every option in glb+ and there doesn't seem to be anything related to brightmaps in software, oh well.

 

2 hours ago, Zaratul said:

Any chance for a pistol start option?

 

Load up crispy-setup, go to keys options, then "other keys" or something similar, find "Restart map" and bind a key of your choice, I for example use home and page down for pistol start/skip map. 

Share this post


Link to post

Here I am boldly opening a new chapter in “SDL, Sound and Music” book.

 

So I've had an old Windows XP system with an ancient-ish Crispy Doom and lots of wads on it, and I've thought of updating. Immediately observed the 2.0.6+ broken sound bug, and decided to downgrade the SDL libraries, then noticed a lot of stuff in the process. It's a bit hard to debug without a log file by guessing what happens from source code and Filemon, but I was not angry enough to configure a full development environment and start adding debug hooks.

 

— Old official binary releases of Crispy Doom are not available anywhere on the internet. It is fun to consider that my existing directories with version 3.2 and 3.3 are now collectible items.

 

— DLL & Music Fix Pack that is officially recommended complicates the issue because it is a fix and a different feature with a different usage instructions at the same time. It would be more straightforward to simply tell people to get SDL2.dll 2.0.5 and SDL2_Mixer.dll 2.0.1 from Chocolate Doom 3.0 or Crispy Doom 5.5 release.

 

— DLLs from DLL pack don't actually work on Windows XP. This is also true for all builds from @Zodomaniac (5.4, 5.7.2, his own So Doom). libgcc (through libpthread) imports GetTickCount64, but libgcc is only used for three division functions that can be statically compiled into SDL2 library at no cost. libfluidsynth depends on libglib, and it imports a number of helper functions from the system kernel, but these will most likely go away with recompile to more specific Windows version target.

 

— With old libraries, midiproc.exe isn't running all the time (with current builds, it is). I guess it was intended to behave that way. Mixer 2.0.1 chooses one of its decoders for MIDI (Fluidsynth, then Timidity, then native) and reports it to the program. However, in 2.0.2+, all MIDI decoders that are in working state are reported, and the check for native midi before running midiproc is always positive. How can anyone release an incompatible library with the same API doing a patch version bump is something I can't understand.

 

It is probably better, and more compatible, to check for Timidity or Fluidsynth being available and initialized, and, if they aren't, check for native decoder and start the midiproc up. The problem is that in current system no one knows whether user chose Native MIDI option to listen to Fluidsynth (configured by external means), or to use the actual system device. Well then, let's use the other way: if GUS option or Timidity configuration file option is set, then disable Fluidsynth from the start, check for Timidity decoder, and use it, else check for Fluidsynth decoder and trust that the user is qualified if it's present, else check for native midi and start the midiproc. Should be fine in general, but someone might have the sound font at some default location that initializes the Fluidsynth, but intend to use native MIDI instead of it. For those people, unconditional off switch for Fluidsynth should solve it. The goal is to eliminate fallbacks, because…

 

— The whole Chocolate+SDL music system nearly drove me mad, it's not based on configuration, but on hints and fallbacks. Those SDL initialization functions (in addition to being incompatible between releases) don't (can't) tell you which decoder would be used for your music (no one checks their return value anyway) because there's second piece of code doing the priority/availability checks on file load. If there was no initialization, the play function will auto-configure the system in a third way. Then there are MIDI decoders that jump in front of each other. Then there are legacy Doom devices projected onto two real back-ends (OPL emulation and SDL). Then there are multiple configuration options that are mashed together into one with vanilla GUS emulation squeezed out as a third leg. Then there is streamed music support that fallbacks to MIDI. Then there's this in SDL source:

#ifdef DEBUG_MUSIC
            /* This would be useful to expose via an API */
            SDL_Log("Music playing with %s\n", interface->tag);
#endif

Yeah, totally.

 

It all makes sense when you want any user system to play at least something, but is a complete mess to study what and when plays. No wonder that even the developers overlook something, as…

 

— midiproc has never been initializing its own copy of SDL Mixer in any way. It simply plays any music in any format Chocolate/Crispy throws at it using a default decoder. Which happen to be MIDI and native MIDI device, respectively, most of the time… UNLESS it finds certain environment variables or timidity.cfg in one of the hard-coded default paths (other fallbacks!), THEN it uses it all the time no matter what is written in the config file. TIMIDITY_CFG is inherited, but the config file is already gone by the time midiproc runs. Hint: leave volume mixer open and click on mute for system synthesizer to check if it's playing instead of trying to guess by how music sounds.

 

It might be possible to force SDL in midiproc to use native MIDI by — you guessed it — setting SDL_NATIVE_MUSIC=1. Its effect is incompatible between revisions (Timidity and Fluidsynth are not initialized in 2.0.2+, but in 2.0.1, native midi is initialized in parallel, while normally it isn't, and takes priority), but at least the final outcome is the same.

 

— On the last day of figuring out why Crispy Doom doesn't play any music through SDL, I noticed that it wants something from D:\temp\doom. It looked like a directory traversal bug because the GUS patches were in D:\temp\doom\dgguspat, among other things, but then I realized I didn't have that path in config files. How did it learn about those at all? And then I realized that it wants to write a temporary file named — quite originally — "doom", and I had a directory there. Yep, can't overwrite a directory with a file, that's an old trick agains autorun viruses.

 

It would be better to add some unique prefix to temporary files, like unix timestamp, at the program initialization, or put them all into a uniquely named subfolder. I remember that you can't run multiple copies of Chocolate doom and its derivatives, this might be one of the reasons why.

 

— I_MidiPipe_SetVolume() is not guarded by midiproc activity flags, and therefore gets called all the time. It is also used to pause/resume music. I'm not totally sure, but it can be the reason of the lags reported earlier. If that happens, writing to a (recently) closed pipe handle and/or waiting for it might vary from system to system.

 

As for the antivirus warnings, simply make a wiki page that explains most of releases come from linux automatic building system, and it's almost improbable to make it produce infected files without directly hacking it. Then tell people that THEY have to report false positives to their antivirus vendors to fix THEIR software errors, as mere developers can't force antiviruses to do anything. In the meantime, there is always an option to add exception for these files or folders.

Share this post


Link to post
5 hours ago, ceyt said:

As for the antivirus warnings, simply make a wiki page that explains most of releases come from linux automatic building system, and it's almost improbable to make it produce infected files without directly hacking it. Then tell people that THEY have to report false positives to their antivirus vendors to fix THEIR software errors, as mere developers can't force antiviruses to do anything. In the meantime, there is always an option to add exception for these files or folders.

 

Don't mean to be "that guy", however there is the infamous Transmission breach which was running for long enough that it was a serious concern.

 

To dismiss all reports as false positives is unsafe.

Share this post


Link to post
45 minutes ago, versificator said:

Don't mean to be "that guy", however there is the infamous Transmission breach

...which, quite ironically, never raised any reports.

Share this post


Link to post
31 minutes ago, versificator said:

 

Don't mean to be "that guy", however there is the infamous Transmission breach which was running for long enough that it was a serious concern.

 

To dismiss all reports as false positives is unsafe.

Sure. I simplified it, as the files don't actually appear on Github automatically, they are uploaded manually, and the user doing it might also be a weak link. Still, an archive from the usual Github repository containing the usual files that only triggers generic detects from lesser antiviruses on VirusTotal while bigger ones remain silent simply screams to me that it is an error that has spread through largely unchecked databases. Theoretically, someone could actively evade detection of top antiviruses and ignore the rest, but that's state level hacking, and Doom isn't an atomic plant control system.

 

To others this might not be so obvious, that's why customer support and false positive submission channels exist. Supposedly, a more or less trained expert will send a response after some amount of time, and you will be told whether a suspicious file actually was a virus.

 

Now I have some additional good news: SDL2.dll 2.0.12 from libsdl website does not produce broken sound! Magic! (Or, most likely, signedness and sample length issues or compiler optimizations.)

Share this post


Link to post
33 minutes ago, galileo31dos01 said:

 

Sounds like you're talking about this

 

Didn't Crispy fix this though?

Share this post


Link to post
2 hours ago, maxmanium said:

 

Didn't Crispy fix this though?

 

I don't think so, as far as I'm aware Crispy removes the static limits, and the archvile fire error isn't a "limit". 

Share this post


Link to post

Crispy's far more than just "limit removing" at this point.

 

Anyhow there was a partial fix for the AV flames a while ago: https://github.com/fabiangreffrath/crispy-doom/commit/43bab7a29e87f935ee8f2ceb0c78c67d4f052d6b

 

If you're not seeing AV flames it would help to provide an example where it could be reproducible, or even better a demo. I personally haven't noticed this being a problem but I haven't really played much lately.

Share this post


Link to post
10 hours ago, ketmar said:

...which, quite ironically, never raised any reports.

That's not the point I'm making.

 

The point I'm making is that many people assume that just because source code is publicly available to view and audit, that makes it automatically safe to download binaries of. The Transmission example shows that is a wrong assumption to make.

Share this post


Link to post
12 hours ago, versificator said:

The Transmission example shows that is a wrong assumption to make.

it also shows that various "protection" doesn't help much. so we're back to point zero: it may or may not be harmful, nobody knows.

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
×