Doom95 compatibility

Spleen said:

If your hardware can't handle low resolutions, you can run ZDoom with the -2 or -4 parameter for pixel doubling or quadrupling, respectively.

Pretty sure this option has been removed a couple of years ago after it was found that it didn't actually improve performance on old hardware anymore.

Gez said:

Pretty sure this option has been removed a couple of years ago after it was found that it didn't actually improve performance on old hardware anymore.

I thought the removed feature was r_detail (in r1134), and -2 and -4 were implemented as replacements.

It was still referenced in December: http://forum.zdoom.org/viewtopic.php?p=474308#p474308

You're right. I thought they were the same thing, but they aren't.

Spleen said:

Wait, really? I thought the CPU was the bottleneck on ZDoom WADs, since the calculations of the software renderer aren't actually being done by the video card, and all it actually sees is the screen data.

The video bandwidth required is just a function of the screen's resolution, bit depth, and refresh rate, and is pretty much constant no matter what the internal renderer does.

The problem is that e.g. in a puzzle game like e.g. solitaire you can just update a few pixels here and there, in Doom you have to redraw every single pixel. 35 or more times a second, if you can keep up. That is "full motion" animation.

A 1024x768 resolution has more than twice the pixels of 640*480, so for a given bandwidth there's a resolution-frame rate tradeoff.

Yeah, the time needed to push the data from the game's screen buffer to the video card is probably small compared to the calculations done inside the engine, but it becomes significant when you're moving towards the low end in both CPU and videocards terms. And by low end I mean all the way down to Pentium I CPUs and S3 video cards (or worse).

Factor in lower memory speeds, lower FSB speeds, shared ram etc. and you'll see how pushing the data around becomes a significant bottleneck. Vanilla Doom never had to render at anymore than 320*200, yet there were videocards that couldn't keep up and were actually part of the total bottleneck. Just moving 1024x768 pixels @ 70 fps requires a bandwidth of 200 MB/sec, which is way beyond what the PCI bus can provide, and is even a stretch for AGP 1x. A 3D accelerated videocard will contain most of this enormous bandwidth on its own board, and will only download texture data and transform instructions from the system's RAM.

Sure, on a modern system, you can give maybe 1% of CPU time to screen rendering and the system bus won't even break a sweat, even in software mode, and devote the remnant 99% to engine calculations.

On older systems, you must start shifting those ratios: 10/90, 20/80, 30/70...and perhaps even lower. Of course under a certain point, the game is just not playable anymore.

I have tried most ports on 400mhz 64mb ram machine with S3virge. Pretty much all software ports ran fairly smooth. Odamex actually seemed the fastest/smoothest.
Even Skulltag with highly adjusted cfg settings ran acceptably smooth on those really big invasion maps with the giant bosses while online.

Catoptromancy said:

I have tried most ports on 400mhz 64mb ram machine with S3virge. Pretty much all software ports ran fairly smooth. Odamex actually seemed the fastest/smoothest.

Do not say Odamex. Say ZDoom 1.22. I think Odamex team does nothing about speed. Randy did all things.

hmmm well,

DOOM95 is a funny engine, it works really wierd and it does give cool gameplay for doom1.wad and doom2.wad ( including any other DOOM IWAD ) beacuse of old graphics, sounds, and classic keyboard control.

i have managed to do funny things for building maps and running the engine, you can for example lock a lowering floor by putting a barrel in the middle of the line that splitts the sectorn, say you have 2 sectors, both are higher floors, that are adjacent.

so to lower the floor, trigger the switch, and blow up the barrel.

:D

I tried to run Doom95 on vista, but it said a certain dll was not found and could not run, and gave the "Doom95 has stopped working and needs to quit" message.

So, I tried Doom95 on virtual pc running Windows 95, sometimes it gives some sort of waveout error, but either way it'll play the music *With Microsoft Virtual PC's awful OPL emulation*, and have a blank screen, and wont close unless the virtual PC is turned off.

Super Flip said:

*With Microsoft Virtual PC's awful OPL emulation*

[opl nitpicking rant]
Actually, Doom 95 can't use the OPL chip the same way vanilla Doom does, it has to go through the Windows MIDI drivers and use it as a MIDI device and use whatever timbres (=instruments) are there, without being able to reconfigure them. And the default Windows OPL timbres suck (in Win 3.1 you could use Voyetra timbres which were somewhat better, with a hack).

This is also true of modern source ports running under any version of Windows, even if you do have a genuine OPL2 and oPL3 chip in your system: they just can't use it "properly". Therefore, you get the dreaded "squarewave banjo" effect on E1M1.

Perversely, you'll get a more "genuine" sound by using the OPL2 emulator in source ports such as ZDoom, rather than a real one through windows's midi mapper.
[/opl nitpicking rant]

Maes said:

[opl nitpicking rant]
Actually, Doom 95 can't use the OPL chip the same way vanilla Doom does, it has to go through the Windows MIDI drivers and use it as a MIDI device and use whatever timbres (=instruments) are there, without being able to reconfigure them. And the default Windows OPL timbres suck (in Win 3.1 you could use Voyetra timbres which were somewhat better, with a hack).

This is also true of modern source ports running under any version of Windows, even if you do have a genuine OPL2 and oPL3 chip in your system: they just can't use it "properly". Therefore, you get the dreaded "squarewave banjo" effect on E1M1.

Perversely, you'll get a more "genuine" sound by using the OPL2 emulator in source ports such as ZDoom, rather than a real one through windows's midi mapper.
[/opl nitpicking rant]

Would you happen to know whether DOSBox emulates OPL and MIDI synthesizers better than modern operating systems?

Spleen said:

Would you happen to know whether DOSBox emulates OPL and MIDI synthesizers better than modern operating systems?

There's no point in "emulating MIDI" as it's not a precise device with a given sound etc. MIDI can be anything from a drum kit to a saxophone. And sadly, no, there's no emulation of classic synthesizers like the moog or the korg prophecy, if that's what you were asking ;-)

When using DOS games that have a "General MIDI" option, you can simply redirect it to the host OS, or use it as you would under DOS: play it through your Soundblaster/Adlib/Rodland (if you were lucky).

AFAIK, no modern OS has register-compatible pass-through OPL2/OPL3 drivers, nor emulation. DOSBOX does emulate a register-compatible OPL2/OPL3 though, by using its own emulation cores.

Even some "SB compatible" soundcards do not actually have fully register-compatible OPL2/OPL3 circuits, but only offer digital sound compatibility and -if you're lucky- an "approximate" OPL playback.

Maes said:

TECH

youre kinda tech guy knowing this, from my point of view.

noticed that threads is more alive during evenings here in sweden.

Maes said:

Even some "SB compatible" soundcards do not actually have fully register-compatible OPL2/OPL3 circuits, but only offer digital sound compatibility and -if you're lucky- an "approximate" OPL playback.

Yeah my SB compatible card on Win98's idea of OPL was what sounded like some electronic farting.

Note that it may seem like just the result of laziness or bad programming that modern ports cannot compete with the vanilla EXE in terms of speed on low-end machines, but you have to consider several factors when thinking about this:

• Vanilla DOOM ran on the bare hardware, barely even calling any DOS functions (only for IO and timer). Modern ports have to run on multitasking graphical operating systems.
  
• Vanilla DOOM used a special page-flipped 320x200 variant of VGA Mode 13 which is blazingly fast, but cannot typically be used as a video mode on modern hardware.
  
• Vanilla DOOM implemented an elaborate dirty rectangles update system which was lost in the Linux version, and cannot easily be restored thanks to incompatibility with a lot of new features that ports want to implement.
  

Taken together, those 3 things alone account for a large bit of the difference. Vanilla DOOM ran very well on my 486DX4 75 MHz, while BOOM, lacking only the latter two factors, ran like complete crap.

You know if good sounding OPL is what you want you should really check out this

John Smith said:

You know if good sounding OPL is what you want you should really check out this

True. And you should stay the fuck away from fake-ass crap like this.

Quasar said:

Yeah my SB compatible card on Win98's idea of OPL was what sounded like some electronic farting.

Note that it may seem like just the result of laziness or bad programming that modern ports cannot compete with the vanilla EXE in terms of speed on low-end machines, but you have to consider several factors when thinking about this:

• Vanilla DOOM ran on the bare hardware, barely even calling any DOS functions (only for IO and timer). Modern ports have to run on multitasking graphical operating systems.
  
• Vanilla DOOM used a special page-flipped 320x200 variant of VGA Mode 13 which is blazingly fast, but cannot typically be used as a video mode on modern hardware.
  
• Vanilla DOOM implemented an elaborate dirty rectangles update system which was lost in the Linux version, and cannot easily be restored thanks to incompatibility with a lot of new features that ports want to implement.
  

Taken together, those 3 things alone account for a large bit of the difference. Vanilla DOOM ran very well on my 486DX4 75 MHz, while BOOM, lacking only the latter two factors, ran like complete crap.

Do some algorithmic optimizations (such as the ones added in by Lee Killough) help offset this, or do they only really make a difference on larger maps?

entryway said:

Do not say Odamex. Say ZDoom 1.22. I think Odamex team does nothing about speed. Randy did all things.

The Odamex team certainly did some optimizations years ago during and after porting to SDL. Even then, why say ZDoom 1.22? Odamex is actively maintained and relevant while ZDoom 1.22 isn't.

@QUasar: yeah, I addressed the OS/API overhead in my previous post. I personally don't like it, but virtualization, abstraction, client-server architectures, high-level APIs and languages is where it's at, for the last 15 or so years, and that comes with a price.

As I said in the Pentium I era: yeah you have the power of 10 486s to play with, but 2 or 3 of them (perhaps more) go just to the OS.

That being said...vanilla DOOM managed to be playable with the -barely- 40 MIPS of a 486 DX/40. A Pentium I @ 200 MHz had about 10x that raw processing power, so even if you factor in quadruple or greater resolution and bigger maps...it's still a major WTF seeing a port of Doom written in C or C++ stutter on machines with 10x power compared to that pentium I....

Spleen said:

Do some algorithmic optimizations (such as the ones added in by Lee Killough) help offset this, or do they only really make a difference on larger maps?

As in the example of the 10 486s that become 6 or 7 after the OS has made them their bitch, a better programming can only help you get the most of what you already have to play with, which isn't little BTW.

IMO, the rendering itself was a major bottleneck in older systems -especially with ISA VGAs-, while the official maps themselves were seldom large or complex enough to cause trouble.

PWADs, however, were another matter, and the slowdown wasn't exactly linear with map size or monster count, which may explain why modern mega-maps can still bring systems to a crawl: a 100x increase in processing power only allows you for 10x bigger maps, or 10x more monsters if the computations behind them are quadratic in nature (Doom is mostly linear though, although some aspects like the map are probably linear-logaritmic, approaching quadratic in some pathological cases).

Well, I took a good look at the error vista was giving me when loading up Doom95, and I downloaded the previously mentioned dplay.dll that it kept saying was required to play.

Put that in my Doom95 folder, and the game worked like a charm, minus mouse controll, but I don't use the mouse when playing classic doom without mouselook.