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

Comprehensive Doom95 guide for newer Windows

Recommended Posts

First of all, let's address the elephant in the room. Why would anyone use Doom95 instead of a source port, it's 2014 right? Wrong, there are many reasons, I've compiled a list:

Spoiler

1) You recently had a brain aneurysm and forgot about source ports. What a shame.

1) First get Doom95 itself, extract it and drop your IWADs in its folder:
http://www.doomworld.com/idgames/index.php?file=idstuff/doom/win95/doom95.zip

2) Copy dplay.dll from the DirectX folder to Doom95's folder to get rid of that missing dll error.

3) Optionally apply this fix to get rid of the crash when recording demos:
gamers.org/pub/idgames/utils/misc/dm95fix.zip

4) Enable the mouse in the options and apply this unofficial mousefix:
http://youfailit.net/files/dmousexp.zip
After installing it, configure it, notice it already adds the -emulate parameter to fix the spectre invisibility issue.

5) After you run it one time, it will create wrapper0.log and probably proceed to write boring stuff in it, making the game lag. So set that file to read-only.

6) You'll probably get the pallete corruption glitch. There are two solutions:
a) Right-click on your desktop, select Screen Resolution, then Advanced settings. As long as that window is open, the glitch is avoided, you'll have to do this each time you want to run Doom95.
b) Permanent solution:
Spoiler

Remember: Backup your registory prior to making any changes to it - Safety First

Step 1: Download / install and run Procmon.exe

Step 2: Run game with all default compatability settings ( eg: none except maybe "run as admin"

Step 3: Alt Tab out of game to Procmon window

Step 4: setup a filter on Procmon -> Path : to "DirectDraw\MostRecentApplication" set as include

Step 5: all going well it should show some entries relating to your game

Step 6: Look at the ID (it'll show up as a DWORD.) you'll need to convert this to a hex value

Step 7: open up regedit.exe and go to section "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectDraw\Compatibility\"

Step 8: Make a new Key in there naming it to something that resembles the game your running

Step 9: make a new Binary value and name it "Flags"

Step 10: double click on that newly created field and type in the Hex values " 00 08 00 00"(it will add in the spaces for you) then press enter

EDITED Step 11: make a new DWORD value and name it "ID"

EDITED Step 12: double click on that newly created field and type in the values you've converted DWORD value as DECIMAL then press enter

Step 13: make a new string value entry named "Name"

Step 14: double click on that newly created field and type in the text from Procmon as displayed for the Name of the program

Step 15: export the entries that you've just made as a backup for future use (eg: on a rebuild of your computer or something)

Source:
http://www.sevenforums.com/gaming/100379-how-i-fixed-corrupt-color-palette-some-old-games-windows-7-a.html
There is a tool to do it automatically but it failed, maybe because I'm on x64, so I had to follow the above guide. Anyway here is what worked on my PC:
Spoiler

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectDraw\Compatibility\Doom95]
"Flags"=hex:00,08,00,00
"ID"=dword:31b6c99b
"Name"="DOOM95.EXE"

IMPORTANT: Now when you run the game, it will STILL probably still be with garbled colors, but don't worry, as soon as there is a palette change, then it fixes itself. So start a new game, or grab an item, or get hit or change the gamma correction and it's fine from then on.

Congratulations, you now have a Doom engine with a nice launcher, that supports Doom/Doom2/UltDoom/FinalDoom, resolutions up to 640x480, oldschool graphics with the awesome smooth lighting around the player, demo support. I also tried fraps and it works fine for recording videos and taking screenshots.

BONUS:
Load this pwad for a grittier palette:
http://www.doomworld.com/idgames/?file=graphics/pal_plus.zip

Share this post


Link to post

Can you, or someone post dmousexp.zip somewhere else? For some reason, I cannot hit that link. Thanks! Nice guide.

Share this post


Link to post

Okay, your reason why made me laugh.

I haven't gone to quite the same lengths but I have managed to get Doom95 at a point working pretty well on my 7 64 box.

The only 'issue' I had was a lack of being able to force always run. I worked around that with a third party program to keep shift toggled.

It was a fun nostalgia trip. Those classy pitched sounds.. how I hate them.

Share this post


Link to post

Never_Again had posted the commandline options of Doom95, here they are:

Spoiler

-320x200 ...... sets screen resolution to 320x200
-320x240 ...... sets screen resolution to 320x240
-640x400 ...... sets screen resolution to 640x400
-640x480 ...... sets screen resolution to 640x480
-320x200w ..... sets screen resolution to 320x200 windowed. Note that
the desktop must be at 8-bit (256 colors) for the
windowed modes to work properly
-320x240w ..... sets screen resolution to 320x240 windowed
-640x400w ..... sets screen resolution to 640x400 windowed
-640x480w ..... sets screen resolution to 640x480 windowed
-altdeath ...... DM rules with item respawns and negative frags
-avg ........... Austin Virtual Game mode, ends the game after 20
minutes
-basewad ....... sets the game mode:
-shareware DOOM, loads DOOM1.WAD
-registered DOOM or Ultimate Doom (DOOM.WAD)
-DOOM2[] (DOOM2.WAD)
-Final Doom - TNT: Evilution (TNT.WAD)
-Final Doom - Plutonia Experiment (PLUTONIA.WAD)
-Doom ] [ French version (DOOM2F.WAD)
-cdrom ......... allows the game to run off the CDROM.
-cmdfrag ....... sets the fraglimit
-comdev ........ development/debugging switch
-config ........ unlike in DOS Doom, seems to have no effect
-deathmatch .... can be used in a single player game, with interesting
effect (items respawn, DM starts are used etc.)
-debugfile ..... development/debugging switch
-devparm ....... development/debugging switch. Displays real-time frame
rate; pressing F1 creates a screenshot
-emulate ....... disables Direct Draw acceleration. Useful with some
video card driver/DirectX combinations, where
transparency (e.g., Specters, invisible effect) is not
handled properly
-episode ....... starts from the first level of an episode
-fast .......... monsters will move fatser and/or shoot more often
-file .......... loads one or more custom WAD(s), can be used with
demos as well (see -playdemo)
-guid .......... Along with -onet it probably has something to do with
connecting to the now defunct DWANGO.
-loadgame ...... loads a savegame (0-5)
-maxdemo ....... overrides the defold memory buffer allocated for demo
recording, in kB
-noblit ........ disables blitting to the screen during a -timedemo
-noclipper ..... doesn't create a DirectClipper object when running in
a window
-nodm .......... skips the Launcher interface, required for most other
parameters to work
-nodraw ........ disables all drawing to the screen during a -timedemo.
Useful for determining system load created by sound
subsystem and AI.
-nojoy ......... disables joystick support
-nomonsters .... no monsters
-nomouse ....... disables mouse support
-nomusic ....... disables MIDI support
-nosfx ......... disables sound effects
-nosfxformat ... disables sound effects upsampling
-nosound ....... disables sound effects and MIDI support
-nowarn ........ skips 'Warning: this Doom version has been
modified...' dialog box when loading custom WADs
-onet .......... ?
-penti ......... forces internal pentium flag (only used for startup
video mode first time game is run ever).
-playdemo ...... loads a demo (must be in the same directory), do not
specify the extension or path. Demos in other
directories have to be loaded with both -file (with
path and extension) and -playdemo (with neither)
-players ....... specifies the number of players (2,3 or 4)
-record ........ records a demo, no extension necessary
-regdev ........ debugging switch used in registered version
development
-respawn ....... killed monsters will respawn
-shdev ......... debugging switch used in shareware version
development
-skill ......... sets difficulty level:
1 (I'm Too Young To Die)
2 (Hey, Not Too Rough!)
3 (Hurt Me Plenty)
4 (Ultra-Violence)
5 (Nightmare!)
-statcopy ...... ?
-sysmem ........ forces video surfaces into system memory
-ticdup ........ (1,2 or 3) compensates for lag in modem games
-timedemo ...... plays a demo and calculates the frame rate which is
frame rate = (gameticks / realticks) * 35
-timer ......... sets game duration, in minutes
-turbo ......... sets player speed, in percents of default speed
-vidmem ........ forces video surfaces into video memory
-warp .......... starts from specified level
-wart .......... loads WAD named ExMy.WAD
-weirdo ........ specifies the respawn delay in seconds for items,
except Invulnerability and Megasphere.

Sadly I discovered that Doom95 has the same limits as vanilla, so the NRFTL exhibits the same problems ... too bad there doesn't exist a doom95plus.exe

If anyone can find the offsets and patch them, that'd be great, there is some info in the doom+ archive.

Share this post


Link to post
VGA said:

Congratulations, you now have a Doom engine with a nice launcher, that supports Doom/Doom2/UltDoom,

and Final DOOM.

VGA said:

Sadly I discovered that Doom95 has the same limits as vanilla,

The MAXVISPLANES limit at least was doubled in Doom95 to accommodate the higher res. On the other hand, Medusa is fatal in Doom95, leading to an instant crash.

VGA said:

so the NRFTL exhibits the same problems ...

You mean VPOs? Tried running in 320x200?

VGA said:

... too bad there doesn't exist a doom95plus.exe

If anyone can find the offsets and patch them, that'd be great, there is some info in the doom+ archive.

Well, I recall entryway stating that he fully disassembled Doom95 in IDA Pro while working on spechits emulation, so if you could get him interested (like the guy with the sponsored HUDs did) he would be the man for the job. I'm sure he could make a DeHackEd95 too if he wanted to; but I doubt he'd ever spend time and effort on something he considers pointless.

A nice guide, though.

Share this post


Link to post

OK, I PM'ed Andreyway.

Doomwiki says Visplane overflow is a fatal error, so it's not that. It's more like not drawing in the distance and creating HOMs. You can see it immediately on the first map looking out of the left window or after getting to the courtyard.

Playing in original res is painful to me and I consider it anti-gameplay. (because the player can't make out stuff, haha)

Share this post


Link to post
VGA said:

OK, I PM'ed Andreyway.

Doomwiki says Visplane overflow is a fatal error, so it's not that. It's more like not drawing in the distance and creating HOMs. You can see it immediately on the first map looking out of the left window or after getting to the courtyard.

Playing in original res is painful to me and I consider it anti-gameplay. (because the player can't make out stuff, haha)

"Not drawing in the distance" is a drawsegs overflow. This isn't an actual hard overflow, as Doom actually checks the drawsegs limit and just stops adding more drawsegs when the array is full.

A drawseg is roughly equivalent to a seg, but scaled and clipped into screenspace. Since Doom draws front to back, the furthest lines away from you will typically be the first to fail to render when the drawsegs limit is reached (it depends on the ordering in the BSP tree).

It is not difficult to trigger this problem. Tarnhill (MAP02) in Strife, a relatively simple map, has one near the door to the Sanctuary if you face toward the Governor's mansion (the inside of the Tavern as viewed through the transparent windows will become HOM if you find the sweet spot).

I do not see the point of anybody going to the trouble of creating hacked versions of Doom95. This obsession with a terrible obsolete port when we have plenty of much more functional properly made source ports is just stretching the limits of reason at this point.

Share this post


Link to post

Why don't you just use Crispy Doom? It has double the resolution of vanilla, supports NRFTL, and maintains an otherwise faithful attention to the original game play.

Share this post


Link to post
Quasar said:

I do not see the point of anybody going to the trouble of creating hacked versions of Doom95. This obsession with a terrible obsolete port when we have plenty of much more functional properly made source ports is just stretching the limits of reason at this point.

Oh, for me it's just nostalgia. And some of us are "in the business of" knowing about the bugs, so being able to recreate them is mildly interesting. Not unlike the Doom alphas and beta.

Share this post


Link to post

@Quasar:

Isn't that a bit of a double-standard?
With a few changes to your post it could be applied to the DOS-EXE as-is.

So aside from being horrendously outdated (just like everything DOS), why should Doom95 be avoided at all costs when Doom.exe should not?

That makes no sense. For many it was the first experience with Doom.

Share this post


Link to post
Graf Zahl said:

@Quasar:

Isn't that a bit of a double-standard?
With a few changes to your post it could be applied to the DOS-EXE as-is.

So aside from being horrendously outdated (just like everything DOS), why should Doom95 be avoided at all costs when Doom.exe should not?

That makes no sense. For many it was the first experience with Doom.

That's another good point - for many, Doom 95 is vanilla!

Share this post


Link to post
Graf Zahl said:

So aside from being horrendously outdated (just like everything DOS), why should Doom95 be avoided at all costs when Doom.exe should not?

Because the latter is the original and the former is not? Or perhaps the squashed aspect ratio, cut-off weapon sprites, slowed-down SFX and lack of autorun have something to do with it?

Graf Zahl said:

That makes no sense. For many it was the first experience with Doom.

Haha. For many DoomLegacy was their first experience with DOOM. Can you think of a more fsckedup and deader port than that? No, ZDoom doesn't count, it's still in active development. (okay, just kidding :)

Oh, and while we are on the subject of horrendously outdated ... A couple of days ago I was forced to download and (attempt to run) GZDoom for the first time in my life. Someone in his innocent ignorance chose the latest version (v2.0.03) of your spiffy engine with GL 4.x support to record a few runs through the recent Switcheroom vanilla megawad. I had a chuckle reading the reports that the demos desynced on the same engine. And a couple more when it turned out that they were recorded with the advanced HUD on and having it off during the playback will lead to desyncs.

Then I tried to see the demos for myself and stopped chuckling:



Not a valid Win32 application, huh?

After reading through the v2.x.x release threads on the DRDTeam forum I found out that you ditched WinXP support. Well done, Graf, who needs that horrendously outdated platform, anyway?
I guess all I have to do is plunk a grand or two on a new system and donate a couple hundreds to Microsoft to keep up with the times.

Share this post


Link to post
Never_Again said:

And a couple more when it turned out that they were recorded with the advanced HUD on and having it off during the playback will lead to desyncs.

As the HUD in Doom does not work like that, fat chance. Unless this so called "advanced HUD" is being more than just a HUD.

Never_Again said:

After reading through the v2.x.x release threads on the DRDTeam forum I found out that you ditched WinXP support. Well done, Graf, who needs that horrendously outdated platform, anyway?
I guess all I have to do is plunk a grand or two on a new system and donate a couple hundreds to Microsoft to keep up with the times.

Well, aside from the fact that Windows XP is horrendously out of date and not actually supported anymore by Microsoft or any major software developer (outside of incidental or legacy support); I have insider knowledge that modern GZDoom does in fact run on XP anyway. And that's XP 64bit, which is even less supported by everyting.

Share this post


Link to post
kb1 said:

That's another good point - for many, Doom 95 is vanilla!


However it obviously has no dehacked compatibility, and you'll find the majority of the community considers dehacked patches to be a vanilla-compatible feature. :p

Share this post


Link to post

Doom 95 lacks a giant decade-spanning archive of high-quality speedruns which depend on it for "level playing field" comparisons. Also, as there is no source code, a "Chocolate Doom 95" is not possible, regardless of demand for it.

Share this post


Link to post

Managing to get Doom 95 to work flawlessly is just a novelty, I don't suppose anyone would use it as his main doom engine. I wouldn't post this in any other forum than Doomworld, it seems that even here there is still a lot of resistance to a thread with a collection of workarounds, I'm a little disappointed.

I just checked gzdoom 1.8.7 and 2.0.03 and they aren't XP-compatible. Probably just due to the compiler options used. Not a big deal imo.

Share this post


Link to post
RjY said:

Doom 95 lacks a giant decade-spanning archive of high-quality speedruns which depend on it for "level playing field" comparisons. Also, as there is no source code, a "Chocolate Doom 95" is not possible, regardless of demand for it.

Never say never. My issue with the idea is, as suggested above, just that Doom95 is a bad port. As a flagship demo product for DirectX, it fails in its basic mission by not even making proper use of the API in a forward-compatible manner. I understand it had to be developed quickly against a draft specification of the API, but, folks, when something is coded badly, it's just coded badly, period.

To me, considering the amount of effort Chocolate Strife took and continues to take (check out how many issues I've found in the last 4 months), there's no way wasting time on a dinosaur like this just to end up with something that most if not all of the features of are replicated in a ton of source ports is worth it.

Share this post


Link to post
kb1 said:

That's another good point - for many, Doom 95 is vanilla!

Not under the definition I follow.

Share this post


Link to post

It is worth pointing out that Doom 95 may contain largely unmolested "real" Doom code. Remember that the original source code release of Doom was for a Linux version, not the original DOS version. Of course, I probably don't know how vast the differences are between the Linux version code and the DOS version code; I doubt I'm in any position to make a claim in relation to Doom95's code authenticity. A good question to ask would be, however; does Doom95 contain any references to DMX?

My point is, while it is a poor port indeed, I do feel that seeing Doom95's source code could prove very beneficial.

On a side note, I do have a certain level of respect for Doom95 despite it being a very poor port. For a while, it was the only way I knew how to play Doom on Windows XP. At the time, I knew nothing about source ports and DOSBOX was still in its infancy.

Share this post


Link to post
fraggle said:

Not under the definition I follow.


I agree, but it was included as the official engine on many releases on CD, including the Doom Collector's Edition, which was targeted at Windows XP where Doom95 especially fails to shine. Nevertheless, the more recent Steam releases of Doom utilize DOSBox, which gives a vastly superior experience compared to Doom95.

Share this post


Link to post
BlueFeena said:

My point is, while it is a poor port indeed, I do feel that seeing Doom95's source code could prove very beneficial.

I doubt beneficial, but it would be a historical curiosity at least. I'd definitely give it a look-over if they ever released it.

Share this post


Link to post
VGA said:

I just checked gzdoom 1.8.7 and 2.0.03 and they aren't XP-compatible.


I checked the latest dev build from November 10 and it's working on XPSP3, albeit with some issues (black screen on resolution change, restarting fixed it).

Share this post


Link to post

I don't get why Doom 95 is hated so much. It's true it runs like shit (have to turn off direct draw acceleration so it's fast in 9x), and the midi music is broken on TNT (Human BBQ). Okay yeah it is kinda shitty lol...

Share this post


Link to post
Edward850 said:

Welcome to Doom since the beginning of Doom. It has always run at 35FPS.

That's my point. It doesn't "run like shit".

Share this post


Link to post
SuperflyJohnson said:

I checked the latest dev build from November 10 and it's working on XPSP3, albeit with some issues (black screen on resolution change, restarting fixed it).



The last official builds habe been accidentally compiled with XP support off. I am using Visual Studio 2013 and so far haven't managed to set this through CMake, so it gets constantly reset.

However, since a lot has happened since then I never made an update.

Share this post


Link to post
fraggle said:

Not under the definition I follow.

That's why I wrote "many", not "all" :)

Gez said:

However it obviously has no dehacked compatibility, and you'll find the majority of the community considers dehacked patches to be a vanilla-compatible feature. :p

Actually, it *could* be done, probably, without too much difficulty. I imagine info.c looks pretty much the same in Doom95.exe as it does in doom.exe. Combine that with the string lookups, and you'd be pretty close. But, yeah, that would not be a project I was interested in spending time on, that's for sure :)

Quasar said:

Never say never. My issue with the idea is, as suggested above, just that Doom95 is a bad port. As a flagship demo product for DirectX, it fails in its basic mission by not even making proper use of the API in a forward-compatible manner. I understand it had to be developed quickly against a draft specification of the API, but, folks, when something is coded badly, it's just coded badly, period.

Heh - I would guess that MS modelled early DirectX with the specific goal of getting Doom95 to run smoothly! If so, they may have done a rush job, and slapped it together "just to get the thing released". I've got no inside info on that, it just seems to match the evidence, and it sounds likely to me.

Quasar said:

To me, considering the amount of effort Chocolate Strife took and continues to take (check out how many issues I've found in the last 4 months)...

I haven't been following Strife bug reports recently. Are you having demo compatibility issues still? I ask, specifically, cause I'd love to get some use out of that hacked strife.exe I built for you way back when. It would find such incompatibilities, and usually point you to the offending action function. Send me a PM, if so, and we'll get it going.

Share this post


Link to post
Graf Zahl said:

The last official builds habe been accidentally compiled with XP support off. I am using Visual Studio 2013 and so far haven't managed to set this through CMake, so it gets constantly reset.

Delete the CMake cache, then through the command prompt in your build directory (replacing .. as appropriate):

cmake .. -G "Visual Studio 12" -T "v120_xp"
Now go to the gui and finish with any additional configuration. Now it will generate XP compatible solutions. Why it's not an option in the GUI is a good question, but at least the feature exists. This only needs to be done once per build directory of course.

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
×