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

Anyone else use Dosbox?

Recommended Posts

Anybody else use DOSBox or some other DOS emulator to play the original DOOM and DOOM 2? I just started today. It's actually quite different than using a modern source port.

Share this post


Link to post

Yes, I specifically use the doom2plus exe for limit extending. I wished Choco Doom had a commandline option for that.

But it feels weird in dosbox, mainly due to the controls and framerate.

Is there a reason you're not using Chocolate Doom?

Share this post


Link to post
VGA said:

Is there a reason you're not using Chocolate Doom?


To be honest, I've never tried Chocolate Doom. There is so many source ports out there that I get confused about some of them.

What makes Chocolate Doom so good? I mean, I've heard great things about it, but lots of source ports are just carbon copies of ZDoom with a different name.

Share this post


Link to post

Not very often. If I want the old vanilla experience, I just turn on my old laptop and that's it. If I don't have it, I'd rather play Chocolate Doom, I don't like to be mounting folders and drives every time.

Share this post


Link to post

Chocolate Doom is not based on ZDoom in any sense. It's basically designed for your exact use case. It's a source port that attempts to recreate the DOS executables in source port form.

Share this post


Link to post
Zed said:

I don't like to be mounting folders and drives every time.

A single click to load up dosbox, mount stuff, launch boom with a pwad and deh, then automatically close dosbox after I exit boom.


$ cat boom.sh
#!/bin/sh
dosbox -conf ~/src/dos/boom202/linux.conf

bottom of linux.conf:

[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
mount c: ~/src/dos/boom202
c:
boom.exe -iwad doom.wad -file wads/dtwid/dtwid.wad -deh wads/dtwid/dtwid.deh
exit

If you are using windows, a .batch file will do the exact same thing.

$ cat boom.bat
cd c:\doom\boom
set dosbox="c:\program files\dosbox-0.72\dosbox.exe"
set doscfg=c:\doom\boom\win32.conf

%dosbox% -conf %doscfg%

Share this post


Link to post
VGA said:

Yes, I specifically use the doom2plus exe for limit extending. I wished Choco Doom had a commandline option for that.

Use Crispy for that.

Share this post


Link to post
facelessdoomer said:

To be honest, I've never tried Chocolate Doom.

Chocolate Doom recreates Doom 100%, along with its bugs. It's kinda like running DOOM in Dosbox just more easy, starts faster, works out of the box etc.

It also has the advantage of supporting Dehacked patches. In Dosbox I suppose you'd have to do the patching yourself like in ... well ... real DOS.

And since Chocolate Doom is a modern program you can use a launcher like ZDL to load multiple wads, add commandline options etc.

If only it had an option to increase the limits :-(

Share this post


Link to post

Chocolate Doom has some sound related discrepancies; one of which I brought up with Fraggle a while back. Also, Chocolate can't emulate any sound related bugs that DMX introduced for obvious reasons. I also think the sampling rate is off a bit, but maybe it's just my options.

I pretty much use DosBox all the time; I can't figure out why people think it's so hard to use. Heck, I even use the original Boom executable if I think I can put up with Windows 7's ear raping sound font.

Then again, I was "actually there" back in the early nineties and playing Doom in any environment that isn't Dos just feels weird.

Share this post


Link to post

It's possible to get DOSbox doom set up with a high mouse sensitivity and all that to make it feel a bit better for people used to a source port. The mouse actually moving the player and lack of autorun take some getting used to, but the vanilla experience is what I grew up with so I'm very fond of DOSbox!

Share this post


Link to post
Doomkid said:

The mouse actually moving the player and lack of autorun take some getting used to, but the vanilla experience is what I grew up with so I'm very fond of DOSbox!


Really? I always thought you had Doom95 as a child. :/

So you had both? It was a choice of resolution over gameplay/glitches/whatever?

Share this post


Link to post

I still use it from time to time, but for the most part, Chocolate Doom works well enough. Before it had OPL emulation however, I used DOSBox more often.

Share this post


Link to post

Setting up GUS emulation is surprisingly easy and totally worth it.

Descent and ROTT midis reach new heights of awesomeness.

Share this post


Link to post

I just use doom.exe on my winxp computer without dosbox. It doesn't have a sound card, but I can use the pc speaker for sound FX (source ports don't even let you do that).

Share this post


Link to post

I occasionally play Doom(2) from DOSBox, mainly when testing if my gimmicky DEHACKED patches and hacky sprite replacements actually work in vanilla. There have been occasions where Chocolate Doom's behaviour was different from vanilla's. I've also used it to see on my own eyes how BTSX works in plain vanilla. For a quick look at the original and unmodded vanilla game (to check something), I also prefer DOSBox over Chocolate Doom.

Share this post


Link to post
TimeOfDeath said:

I just use doom.exe on my winxp computer without dosbox. It doesn't have a sound card, but I can use the pc speaker for sound FX (source ports don't even let you do that).


Chocolate Doom and Eternity engine support PC Speaker emulation, but I don't think it allows passthrough like Chocolate Doom allows for OPL.

As for me, I only use Dosbox for Boom. The other ports I like to use as of this writing(prboom-plus trunk and chocolate doom trunk) don't require Dosbox.

Share this post


Link to post
fraggle said:

Chocolate Doom is not based on ZDoom in any sense.


Just tried Chocolate Doom. Practically like running it on my dad's old DOS computer. Much easier too, as you said. Thanks for the recommendations!

Share this post


Link to post
scifista42 said:

There have been occasions where Chocolate Doom's behaviour was different from vanilla's.


Can you name them? I hope by behavior changes the only differences you note are small things, like lack of dmx glitches; integrated novert, -merge, etc; tcp/ip instead of ipx; limited bex support (for strings only)...nothing that affects compatibility. If not, it would be nice to know, after all, there is always the possibility of demo desync. I guess if you were to record a multiplayer demo you would rather use doom2.exe than chocolate doom?

Share this post


Link to post
Danfun64 said:

Chocolate Doom and Eternity engine support PC Speaker emulation

But you need a soundcard to hear the emulation, right?

Share this post


Link to post
Danfun64 said:

Can you name them? I hope by behavior changes the only differences you note are small things, like lack of dmx glitches; integrated novert, -merge, etc; tcp/ip instead of ipx; limited bex support (for strings only)...nothing that affects compatibility. If not, it would be nice to know, after all, there is always the possibility of demo desync. I guess if you were to record a multiplayer demo you would rather use doom2.exe than chocolate doom?

Some bugs the vanilla exe has *cannot* be accurately emulated, outside of running the original code in an emulation or virtualization core somehow (at which point you're going back to using DosBox pretty much). Bugs that happen in Doom which invoke effectively random behavior dependent on heap contents, stack layout, or the behavior of DOS4GW with respect to accesses to low DOS memory may not behave in deterministic manners. SOME of these such glitches have been successfully emulated via empirical testing in DOS and extraction of the necessary conditions, but on occasion "magic numbers" are still necessary, such as in the case of spechit overflows - the value the spechit array will be filled with is non-deterministic under DOS, depending on the base address the process was loaded at by the extender. Just an example.

Share this post


Link to post
TimeOfDeath said:

But you need a soundcard to hear the emulation, right?


I thought I said that when I mentioned the inability to passthrough to the real pc speaker.

Quasar said:

Some bugs the vanilla exe has *cannot* be accurately emulated, outside of running the original code in an emulation or virtualization core somehow (at which point you're going back to using DosBox pretty much).


So how does this affect demo compatibility?

Share this post


Link to post
Danfun64 said:

I thought I said that when I mentioned the inability to passthrough to the real pc speaker.

So how does this affect demo compatibility?

A stair sector could create a random sector type, or a plat could bounce and go to a different height, just two examples of behavior in DOOM that depend on the semi-random contents of the heap, due to use of uninitialized data. Trust me that there are many others.

Share this post


Link to post
Danfun64 said:

Can you name them? I hope by behavior changes the only differences you note are small things, like lack of dmx glitches; integrated novert, -merge, etc; tcp/ip instead of ipx; limited bex support (for strings only)...nothing that affects compatibility. If not, it would be nice to know, after all, there is always the possibility of demo desync. I guess if you were to record a multiplayer demo you would rather use doom2.exe than chocolate doom?

I meant occasions when vanilla crashed. I think that custom sprites with new names replaced via DEHACKED sometimes refused to work for me in vanilla, even though they theoretically should and in Chocolate Doom they worked. It was in combination with custom DEHACKED monsters in Doom 1 replacing D2 things, with editor ids changed via DEHACKED. Maybe it weren't real compatibility issues and I just did something wrong. I've eventually solved both problems to become fully vanilla-compatible.

I've also heard a MIDI working in vanilla but breaking Chocolate Doom (2.0), it was in this wad.

Share this post


Link to post
Danfun64 said:

I thought I said that when I mentioned the inability to passthrough to the real pc speaker.

Well, I had no idea what "but I don't think it allows passthrough like Chocolate Doom allows for OPL." meant. Not sure why you'd mention pc speaker emulation at all, because the point of my post was having sound FX without a sound card. :)

Share this post


Link to post

Chocolate Doom certainly supports passthrough to a real PC speaker, although it can be tricky to set up, depending on your OS. It's probably easier to just use the PC speaker emulation; are there any computers nowadays without digital sound output (ie. a sound card)?

scifista42 said:

I've also heard a MIDI working in vanilla but breaking Chocolate Doom (2.0), it was in this wad.

I've said this before, but please report all OPL music bugs that you find in the Chocolate Doom issue tracker. There are certainly still some known issues with OPL emulation, but I have been trying to shake these out.

Same goes for any other differences in behavior you find. My goal is to make a source port that reproduces Vanilla Doom as accurately as possible, but I can't do that if people don't report bugs. Even if it's something that's hard or impossible to emulate, it deserves to be investigated and at least documented. Sometimes weird DOS behaviors that might seem impossible to reproduce actually are possible to emulate (entryway has done amazing work adding emulation for overflows in PrBoom+, and I've done my best to try to incorporate his workarounds into Chocolate Doom).

Share this post


Link to post
VGA said:

It's kinda like running DOOM in Dosbox just more easy, starts faster, works out of the box etc.


And has much lower system requirements. My netbook couldn't run Vanilla Doom in Dosbox at full speed, but Chocolate-Doom was full speed.

BlueFeena said:

Heck, I even use the original Boom executable if I think I can put up with Windows 7's ear raping sound font.


Installing the Timidity audio driver is nice for this.

Share this post


Link to post

fraggle said:Same goes for any other differences in behavior you find. My goal is to make a source port that reproduces Vanilla Doom as accurately as possible, but I can't do that if people don't report bugs. Even if it's something that's hard or impossible to emulate, it deserves to be investigated and at least documented. Sometimes weird DOS behaviors that might seem impossible to reproduce actually are possible to emulate (entryway has done amazing work adding emulation for overflows in PrBoom+, and I've done my best to try to incorporate his workarounds into Chocolate Doom). [/B]


Did you already added OPL support for heretic/hexen/strife? Do you require testing/reporting bugs of OPL?

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
×