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

Crispy Doom 6.0 (Update: Mar 31, 2023)

Recommended Posts

Quasar said:

Sounds like the usual SDL bug which is caused by Windows not having a proper MIDI volume control setting per process.

Graf Zahl said:

I'd say these days it's a bug to even USE the native Windows MIDI stuff... >) Maybe as a fallback but not as the primary playback option.

You know, the real shame of all of this is that MS had all of this working fine, and they went and broke it, using their same old BS excuse: "But, new stuff... We just couldn't keep it... just use X instead.". Had it been Bing, or Windows 10 related, you can bet they would have figured out how o make it continue to work...

Quasar, you had a nice solution: A separate process for MIDI, forcing the OS to give you a separate volume control, right? How do you control it?

My guesses are:
1. Pass it a MIDI file, and file-based start/stop/pause.
2. Some type of ActiveX property marshalling thing.
3. Memory mapped file.
4. TCP/UDP

Do tell, please :) At any rate, a nice workaround, not unlike the Linux source release hinted at.

Share this post


Link to post
kb1 said:

Quasar, you had a nice solution: A separate process for MIDI, forcing the OS to give you a separate volume control, right? How do you control it?

My guesses are:
1. Pass it a MIDI file, and file-based start/stop/pause.
2. Some type of ActiveX property marshalling thing.
3. Memory mapped file.
4. TCP/UDP

Do tell, please :) At any rate, a nice workaround, not unlike the Linux source release hinted at.


Why not just use stdin and write instructions to it, exactly how the Linux sound server worked?

Share this post


Link to post
Jon said:

Why not just use stdin and write instructions to it, exactly how the Linux sound server worked?

How does that work? Will the sound server continue to listen to the game exe? How do you communicate with it exactly? (Seriously, I'm curious how you'd set up the code on a Windows platform. Doesn't the sound server app have to pool/listen for these commands? Funny as it sounds, I never understood the stdin/out stuff, even though it could be considered programming 101 - heh.)

Share this post


Link to post

My solution uses RPC. It isn't needed on Linux so there's no reason for it to be coded portable.

Share this post


Link to post

Update 27 Dec 2016: Crispy Doom 3.5 is released!

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 compatibile with the original.

This release introduces some major new features as well as refinements and bug fixes.

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.5.zip
http://www.greffrath.com/~fabian/crispy-doom-music-pack_2.zip

Have a lot of fun!

- Fabian

Share this post


Link to post

Just as a heads up for any other Windows users who experienced a similar issue to me --

This has become by far my favorite source port, as I simply wanted a vanilla Doom experience with the option for slightly higher resolution, but since downloading it, I always seemed to experience a choppy framerate in its capped FPS mode. It was very subtle, so much so that I actually wondered if I was imagining it, but sure enough, it was consistently choppier than either Chocolate Doom or DosBox (which has its own inconveniences). It didn't seem to be a computer performance issue, as I was able to run more strenuous ports without issue. It was mostly obvious when running long distances.

I finally this afternoon found an old GitHub issue that noted Windows users may have trouble with this if vid_driver isn't set to directx is the config file. Made that switch and the problem was completely fixed! Just wanted to throw this out there, as it'd been bothering me for a while, and it took a bit of digging to find the answer (maybe it would have been more obvious to those more computer literate than I am). Happy to finally be able to play this port without this one issue.

GitHub link: https://github.com/fabiangreffrath/crispy-doom/issues/71

Otherwise just wanted to say thanks for such a great source port! It's all I could imagine ever needing! Seriously, thanks for putting this out there.

EDIT -- I guess it's worth noting that I have had the Native MIDI balancing problem in Windows noted last page, but that's obviously a known issue and OPL works just fine (had to get used to the "softer" sound of the music versus the MIDI versions I was used to in other ports, but it's faithful to the original, so it's all good).

Share this post


Link to post

Just install Coolsoft VirtualMIDIsynth and you have a proper replacement for the native MIDI player of Windows. And a separate volume control and equaliser, soundfont support etc.

Share this post


Link to post
VGA said:

Just install Coolsoft VirtualMIDIsynth and you have a proper replacement for the native MIDI player of Windows. And a separate volume control and equaliser, soundfont support etc.

Ah, thanks. If that doesn't seem too involved, I might go for it.

Share this post


Link to post

I can't get E1M10 to work under Crispy DOOM. I have added the map into the .wad, named as E1M10, and I have marked the wall in E1M1 as secret exit, but it keeps bringing me to E1M9.

IDCLEV10 doesn't work either.

If I overwrite a different map with it, it loads fine, so there is no issue with the actual map. I just have problem accessing it.

I have same issue with MAP33 in DOOM II

Help me please?

Share this post


Link to post

You also need to add the graphics lumps with the map name captions for the intermission screen. They are called "sewers" for E1M10 and "cwilv32" for MAP33.

Share this post


Link to post

After hour of copying files across the .wads, it still doesn't work. E1M1 brings me over to E1M9 and MAP02 brings me back to MAP01.

IDCLEVing doesnt work either. I have copied all graphic lumps from the xbox .wads and I have overwritten E1M1 and MAP02 with the Xbox version, even though they seemed identical to the versions I made in DOOM builder.

Sigh.

If there is anyone here who managed to get E1M10 and MAP33 working, could you send me your .wads in PM please?



(un)related question, would it be possible for Crispy DOOM to support zDoom's MAPINFO in the future?

Share this post


Link to post
chungy said:

If you've made the xbox IWADs, just load them in Crispy directly with -iwad.


I did but Crispy DOOM still keeps bringing me into E1M9 when i use the secret exit.

Share this post


Link to post

Both .wads have the correct size.

DOOM 2 wad loads fine in crispy doom and brings me to MAP33 correctly from MAP02

DOOM 1 wad brings me to E1M9

when I copy over the map files (inlucing graphics and everything related to those maps) into the normal wads (with crosses on health packs and uncensored wolfenstein levels etc.), both bring me into the normal secret maps (E1M9 and MAP31)

Share this post


Link to post

So, can you guys help me figure out a mystery?

Why is it that no matter what I do, I seem to get lower quality sound effects and music in Chocolate/Crispy Doom (though Crispy has far better SFX than Choco did for me out of the box), than I do emulating the games in DosBox?

I've tried all three audio settings in Crispy for music (native MIDI, OPL, and the GUS emulation patch), and none of them sound close to DosBox under its Soundblaster settings, which is consistently a little deeper and fuller sounding. The sound effects are also noticeably less full than in DosBox, though again, better than Choco was for me.

What is actually happening to cause the difference? How is DosBox actually getting those sounds out of my computer, since as far as I know it's still just using MIDI, and why does it consistently sound so different/better than Crispy? This might sound ignorant, but I'm literally confused as to what is happening on the backend. Also, are there tweaks I can make to Crispy to get closer to those sounds? I still love the port, but sound is important to me, and I've been going back to DosBox a fair bit now that I've got it running smoothly.

Operating system is Windows 10, if that makes any difference for troubleshooting/known issues. As far as I can tell, this is different from the MIDI volume issues brought up above, especially since my setup is obviously capable of getting the kind of sound I want; I'm just not sure how to get Crispy to match it. All explanations/help appreciated!

Share this post


Link to post
AlexMax said:

Do you plan on following Chocolate Doom to SDL2 anytime soon?

Yes, of course. I'll follow suit as soon as Choco merges the sdl2-branch.

Cipher said:

(though Crispy has far better SFX than Choco did for me out of the box),

Crispy has libsamplerate support compiled in by default, this probably makes the difference for sound effects. As for the music, I have no idea why it sounds different on Windows, sorry.

Share this post


Link to post

Well, if you install Coolsoft Virtualmidisynth and use the native MIDI option in the setup, then you can use any soundfont you want and get the sound you believe is best.

For example, Patch93's sc-55 soundfont.

Share this post


Link to post
fabian said:

Crispy has libsamplerate support compiled in by default, this probably makes the difference for sound effects. As for the music, I have no idea why it sounds different on Windows, sorry.

Ah, thanks. I was pretty sure the libsamplerate was the difference (I remember looking for a Windows guide for compiling that into Chocolate, and found it a little over my head). On that note, after a little more comparison tonight, I got the sound effects to be more or less indistinguishable from DosBox after pumping up their volume in Crispy, so I think it was just a balancing issue and going back to DosBox to compare was throwing me off.

As for the music, oh well. I can do reasonably well with different soundfonts -- currently using Native Midi with eawpats, which is okay -- but nothing quite sounds as crunchy as whatever DosBox is doing for Soundblaster emulation. Maybe I'll find the soundfont I'm looking for eventually. Nevertheless, I can live with it for now. Thanks!

None of this is stuff I would have noticed at all had I not just downloaded Doom II and given it a run in GOG's DosBox setup, so it's not a big deal.

May have to try out that SC-55 soundfont. Thanks to the post above for the suggestion.

Share this post


Link to post
chungy said:

Need to run it with the BFG version of doom2.wad too.

No you don't. In fact I just tested it with the regular 1.9 doom2.wad and it worked just like it was supposed to. You might have been confused because even with doom2.wad, you get interpic instead of titlepic if you have nerve.wad loaded. What you have to do is either "crispy-doom(.exe) -merge nerve.wad" or "crispy-doom(.exe) -file nerve.wad"

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
×