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

Doom95 mouse fixed - what now?

Recommended Posts

While I was developing the mouse fix for doom95 I was made aware of an array of problems it has. My instinct tells me that the mouse problem was relatively easy compared to some of the other problems. Nevertheless, I would like to explore these issues and determine the feasability of fixing some of them or making better fixes than are already present.

I perceive the invisibility problem to be the most prominent. As already noted, there is a workaround for this by using the -emulate option in doom95. But this results in tearing due to lack of vertical sync. It has been noted that doom95 dosen't support DeHackEd. As far as I can tell DeHackEd is for customizing the Doom
executable. This might seem to be an impossible problem to tackle - but maybe we can accomplish something almost as good. At the end of the day Doom95 is in principle changeable. There are probably lots of places where we can insert hooks, reassemble, and customize its behaviour.

The purpose of this thread then is to brainstorm on possible solutions in principle to any of the remaining problems in Doom95.
If you have even a vague idea of how a problem might be solved or improved and you want to share it - then please do!

We are not allowed to say that its too difficult, doom95 is too old, we know of no solutions therefore there aren't any. This should be veiwed as a recreational excersize to overhaul doom95 and bring it on a par with the competition.

Share this post


Link to post

If you'd like I can load up the EXE and start mapping it out. My resume of games shaken down via IDA include Strife (demo, 1.2, and 1.31), the DOOM Prebeta, Heretic 1.0, and Shadowcaster.

Any time source code is available for a majority of the executable, the task of reverse engineering the whole thing becomes relatively trivial.

Share this post


Link to post

What about the fact that the sounds are lower pitched than in normal Doom? Can anything be done about that? That was always one thing that really bothered me about Doom 95 back in the day.

Share this post


Link to post

A fix for episode 4's intermission in Ultimate Doom would be nice. It reuses the map and graphics from episode one.

The non-emulated spectre issue is really bad on this card I have now - back on my laptop they just drew black on flats and everything else was normal, on here they're really weird looking, like a walking HOM. You can see the status bar in them, and they slow the game to a crawl anytime they're in view.

I also get a constant tone playing after exiting the game, barely audible at first, but it gets louder every time Doom95 is exited until I restart. That might have something to do with how I have MIDI set up to play on here though, if no one else experiences it.

Share this post


Link to post

Doom95 has problems recording demos since using the UI's options to record a demo results in a CTD. Using the -nodm + -record commands works fine though.
Playback functions normally through the UI. However, since the D95 engine has different limits, 1.9 demos are not always %100 compatible; a short one-level demo will probably play without fail, however it starts to desync in longer demos (playing the recent 30NM speed screws up around MAP06). So it's pretty much intended for demos recorded in D95, similar to how other source ports playback demos.

Here's documentation of the Doom95 engine if you're looking for more bugs/nuances.

Share this post


Link to post

That sounds like a good idea Quasar. Lets see what information you can come up with.

Now I'm wondering, the problem with the partial invisibility seems to always be described in terms of what graphics card its running on. Is it dependent on what hardware its running on? Was there ever a hardware setup where the effect ran properly without the -emulate setting. It would seem strange for Microsoft to release a game with such an obvious bug in the first place. So did they write the effect to run on particular hardware and it ran ok - but then not ok on newer hardware? Why did they put in the emulate option?

Does DDraw.dll provide any abstraction from the hardware or is it merely allowing direct access to the raw hardware. If its basic function is to literally provide direct access then could the fix take the form of a new DDraw.dll that takes account of the particular way that doom draws and can also properly render to a window.

Share this post


Link to post

I think the problem comes from how the graphics memory can be accessed. It looks like they assumed they'd always get a readable frame buffer. But apparently that's not always the case if you get direct access to the hardware buffer.

The -emulate option was for those obnoxious graphics cards that couldn't handle DDraw directly.

Share this post


Link to post
Quasar said:

My resume of games shaken down via IDA include Strife (demo, 1.2, and 1.31), the DOOM Prebeta, Heretic 1.0, and Shadowcaster.

Speaking of which, did you find anything potentially useful in the CD versions' RLE function?

Share this post


Link to post

Oh yes. The partial invisibility is a blending function. It would need to read the background colour from somewhere. They could have assumed they could always get that from the hardware.

Then a solution based on that could in principle work by duplicating the data written to the hardware in a local buffer. Then redirect any read of the hardware buffer to the local buffer.

Share this post


Link to post

One thing to keep in mind is that Doom 95 was the *first* DirectX program, and in fact it even predated DirectX, as it was derived from the WinG-based WinDoom port for Windows 3.1. So the technology was new, and I wouldn't doubt still developing as the program was being worked on. This probably explains some of the problems by itself.

Share this post


Link to post

Also because of lack of doom95 level of compatibility PrBoom-Plus has "-doom95" command line switch for correct emulation/detection of stack overflow in P_FindNextHighestFloor, because doom95 raises MAX_ADJOINING_SECTORS limit from 20 to 500. (SVN description says this emulation is needed for napalm.wad by Eternal)

Share this post


Link to post
Never_Again said:

some of the info there is plain wrong

If you notice errors on the Doom Wiki, it would be great it you went ahead and fixed them yourself. It would certainly be more helpful than to post the factual corrections here instead. The wiki won't fix itself after all. ;-)

To get back on topic, I'd say that in addition to the invisibility effect problem, my biggest gripes with Doom95 are:

  • The squished graphics and the bloated player weapon sprite proportions; look here for a comparison shot. It's pretty bad, at least in 640x480.
  • The inability to play MIDIs not converted to MUS, which affects PWADs such as Alien Vendetta.
Furthermore, I'm having severe difficulties in getting the Doom95 multiplayer to work on Windows 7. Even though I've already copied the dpwsock.dll file to the Windows system32 directory, the launcher still whines about the file missing and crashes whenever I try to start an actual match.

If these concerns could somehow be addressed, I would certainly consider Doom95 a usable port.

Share this post


Link to post

Seriously, considering the issues of Doom95, wouldn't it make more sense to use Chocolate Doom, add a render that can scale to higher resolution and maybe lift a few of the limits that got increased in Doom95? The end result would certainly be more usable than this ancient PoS.

Share this post


Link to post

I almost want to say I have nostalgia and fun memories of Doom95. I guess it's just an interest to see "how much it can be improved" at this time. Though the idea of a "Chocolate Doom 95" with the Doom95 limits/resolution and without the bugs certainly sounds fun...

Share this post


Link to post

A "Chocolate95" would have to disable dehacked support, and replicate inaccurate sound pitches, erroneous aspect ratio, and MUS stubbornness faithfully. ;)

(Oh, and be closed-source. :p)

For the rest, playing Doom in a Windows port without the bugs? There is a vaaaast array of ports to choose from.

Share this post


Link to post

I have incorrect gammapalette when I use doom95 on Win7. All is ok for WinXP. So it is still unusable on modern systems. At least for me. Does somebody have no problems with palette on Win7?

P.S. I have the same issue with gamma in chocolate-doom when video_driver = directx. Also I do not know how doom95 sets 640x480 fullscreen, because 800x600 is minimal resolution which is reported by EnumDisplayModes. Probably IDirectDraw2_EnumDisplayModes returns something different, I did not check 'directx' mode with prboom+.

Share this post


Link to post

Janizdreg said:Furthermore, I'm having severe difficulties in getting the Doom95 multiplayer to work on Windows 7


Getting anything older than Vista to work correctly on anything newer than XP means severe difficulties.

Let's just take this for what it is, a "recreational exercise" Anyone seriously considering doing something for a Vanilla-oriented port should jump into the chocowagon.

Share this post


Link to post

I think the probability of a lot of the problems that people are moaning about getting fixed is very poor. Especially stuff like MIDI support, considering how much modification that would require to the binary code.

At least on Windows exe's you don't have to mess with stuff like relocations.... I've had my fill of that with the DOOM prebeta already >_>

Share this post


Link to post

Never_Again said:
Probably the most obvious and annoying issue with Doom95.

The -nosfxformat parameter gets rid of that. It still does sound "deeper" than when running Doom on Windows 9x, but so does true DOS, at least on a same Sound Blaster card.

The desyncs have nothing to do with demo length. I'm positive that Doom95 records and plays back all demos with the Ultimate DOOM compatibility, regardless of the IWAD. prBoom-plus with "-complevel 3" desyncs on that NM run (skogsto's nm302939) in the same spot as Doom95 - at about 0:58 into MAP06. With "-complevel 2" a Lost Soul bumps the player, with "-complevel 3" it misses him first. The demo actually gets subtly out of sync earlier. As the player enters that area, his first rocket kills only one of the two sarges. With "-complevel 3" it kills both. It's a fascinating subject to study in another thread, but the bottom line is Doom95 == "-complevel 3".

Yeah, if any hack would be particularly interesting, it would be to add something like -v19demo and -finaldemo parameters (or -gameversion 1.9 and final to do it like Chocolate) forcing the engine to behave like the DOS counterparts.

I did some tests in late 90s on Win95 OSR2. When I installed Doom95 along with its accompanying DirectX 3 from the CDROM, there were no problems with invisibility. As soon as I upgraded to DX5 invisibility was broken.
So I don't think this is a purely h/w issue.

Hardware does matter, though, because on the same computer, with the same Windws 98 install, I have the issue with a SiS card but not with an old Trident card I've used. Maybe the DirectX vsync function was added after DX 3, and either only works well on some hardware, doesn't adversely affect hardware that isn't compatible with the feature, or both.

I have -emulate enabled on Doom95 and I must say I don't really notice any screen tearing, so it doesn't seem like a big issue. At least nothing compared to how Boom behaves, which has some visible screen glitching.

Share this post


Link to post

Does anyone have any idea what this error would be loading a pwad:

Z_CT at w_wad.c:530

I get that when attempting to load the Jaguar TC in it, which works fine with the vanilla exe and every other port I've thrown it at. I can send the wad over if anyone wants to have a look, my only idea was to break it apart into multiple wads and test different resources separately.

Edit: Well, figured this out a lot faster than I expected. Seems like it doesn't like the custom colormap I generated with Inkworks.

Share this post


Link to post
Bashe said:

What about the fact that the sounds are lower pitched than in normal Doom? Can anything be done about that? That was always one thing that really bothered me about Doom 95 back in the day.

That was always one thing that really delighted me about Doom 95. That's really the only reason I'd choose Doom 95 over another port. At least, add a compatibility mode for it.

Share this post


Link to post
Never_Again said:

The last sentence is missing a "really". It looks as if you lost momentum after typing the first two, and only kind of want the compatibility mode. Quick, change that to "At least, add a compatibility mode for it; no, really" or your request won't be taken seriously. :P

English is not my first language.

Share this post


Link to post

Doom 95's sound is higher pitched than in Vanilla? I don't think so, Vanilla Doom was higher pitched than normal. Doom 95's sound pitch is lower which I don't care either way, sounds better.

Share this post


Link to post

It's lower-pitched, much like in the true DOS Sound Blaster driver, from personal experience. My impression is that they did it on purpose.

Never_Again said:
Also, the only difference I noticed between vanilla's SFX in DOS and under Win98 is that they tend to break up under Win98 when combined with OPL music.

Weird... maybe your cards didn't behave like a Sound Blaster 16, or some newer drivers give Sound Blasters sound equivalent to that of Windows.

Two SB Live!s exhibited that flaw, the SB-16 and the Yamaha OPL-SAx don't.

That means the Sound Blaster Live! sucks for DOOM. I'll keep it in mind if I ever need to hunt for extra Sound Blaster compatible cards :p

The Sound Blaster 16, Sound Blaster 16 Value (the cheap version) and Sound Blaster 32 (a cheaper AWE32) cards that I've owned all did or do it right.

Share this post


Link to post
entryway said:

I have incorrect gammapalette when I use doom95 on Win7. All is ok for WinXP. So it is still unusable on modern systems. At least for me. Does somebody have no problems with palette on Win7?

I have Windows 7 and the palette looks fine to me, apart from the game being a little bright as seen here. What exactly is wrong with the palette on your system?

Share this post


Link to post
Janizdreg said:

What exactly is wrong with the palette on your system?

Something like that
http://prboom-plus.sf.net/doom95.png

PrintScreen makes it different from what I see, but it is similar. Status bar is ok though.

I have absolutely the same issue with chocolate-doom at fullscreen and video_driver "directx" (prboom-plus is ok with sdl_videodriver "directx")

I use WIn7 x64

Share this post


Link to post

I get that with most 256 color fullscreen games, but Doom95 isn't one of them. There's a DirectDraw compatibility flag you can toggle in the registry to fix it. After running the game, check this key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectDraw\MostRecentApplication

Take the bytes in ID and reverse them, then make a new key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectDraw\Compatibility\[game name]

Look at the entries already there to see how they're set up. ID is the four bytes you reversed, the flag you want is 00 08 00 00. Can't say if it'll work for you, but I originally found out about this from a fix for StarCraft, and used it with Command & Conquer.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×