VOGONS

Common searches


First post, by gerwin

User metadata
Rank l33t
Rank
l33t

I used to think the source ports were an improved over the original in every way. But on a 486 system I noticed some Framerate differences:

Benchmark Doom 1 "- timedemo demo3" (E3M5), with 1 level of green border and sound+music:
System: Cx5x86-100MHz (LSSER FP_FAST BTB), 256kB L2, 16MB RAM 60ns, CL5428 VLB graphics

Doom 1.9 original   42,2 FPS
BOOM v2.02 33,7 FPS
MBF 2.03 31,7 FPS (no pageflip, no translucency, no vsync)
MBF 2.04* 32,9 FPS (no pageflip, no translucency, no vsync)
MBF 2.04* 28,2 FPS (pageflipped, no translucency, regardless of vsync)
Eternity 3.31b7 28,1 FPS (no pageflip**, no translucency, no vsync) green border looks glitched
DosDoom v0.65 Won't do the timedemo
Doom Legacy v1.41 Won't do the timedemo, nice port otherwise..

Regarding visual quality: Original Doom is triple pageflipped, and should be compared to a port that uses normal pageflipping together wih vsync. Doom framerate was capped at 35 FPS; the 'Ticrate'. My benchmarks suggest that generally any 486DX4 or above can maintain this 35 FPS Ticrate when running the original Doom. Unfortunately none of the source ports can. The reason for this is that the released source was based on a linux port, it came without the original pageflipped drawing system. Seemingly no one bothered to optimize the source for 486s again. At least, not sufficiently.

For Pentiums I did notice different code, so things may be different there. Same for Pentium Pro/II, but these systems are so fast that the 35 FPS is easily reached, so none of this is a concern there.

*I was hoping I could maintain/adjust 'Doom: Marine's Best Friend' (MBF) to make a nice benchmarking version for 486s and above. That is why I mention a v2.04, which is not yet available online. Although I succeeded in most of my goals, the 33% lower framerate makes it undesirable for 486s. For faster DOS systems that can handle its 640x400 mode; MBF is great.

**have to check if pageflipping was really disabled, because the score is rather low. Eternity is based on MBF.

The Quake source is much easier: the DOS version compiles as is. It was compiled with the GNU licenced DJGPP instead of Watcom. The sound related code was included.

Related:

Filename
Carmack-Doom_graphics_mode_05-1994.pdf
File size
61.18 KiB
Downloads
739 downloads
File comment
John Carmack's info on the doom graphics mode
File license
Fair use/fair dealing exception

Discussion on doomworld forums, 2011
John Carmack's readme for the Doom source

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 1 of 17, by Holering

User metadata

Seems like the original Dos versions are somewhat unique compared to the sourceports (original linux code included). I remember Carmack on an interview talking about Linux framebuffer being awfully slow; I wonder if that has anything to do with it? Over 9 FPS difference seems a bit big IMO.

Reply 2 of 17, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie

I know from using MBF on a 486DX 33Mhz that source ports can be painfully slow. Of course, that system just never ran Doom well in the first place, even after upgrading it to a DX2 66, then an AM5x86 133. 🤣 The last time I used that box was 5 years ago, though I remember it had a 2MB VLB Mach64, and 20MB of system ram, along with a Contaq chipset. I've never been able to identify what exact model the motherboard is, probably some generic POS with fake cache or something.

Strangely, I remember it ran Heretic OK, as well as Terminal Velocity and ROTT. Duke3D and Doom were dog slow though.

I remember I had another 486 box with a DX2 66-S, along with only 8MB of ram and a 1MB Cirrus Logic VLB card of some sort, but it ran Doom quite well, and I didn't even have to set it to low graphical detail to make it playable. It had a newer motherboard though, a 1993/1994-era ASUS of some kind, and for most of its life it was a decent system. I eventually threw it out though, because it became really unstable after a while, and it would crash whenever I ran Doom. Looking back, the hard drive upgrade I did on it was probably to blame, but I was much younger and didn't have as much experience messing with computer hardware. It's a shame I threw that system out.

Reply 3 of 17, by gerwin

User metadata
Rank l33t
Rank
l33t
mr_bigmouth_502 wrote:

Strangely, I remember it ran Heretic OK

I read that Heretic uses the same 320x200 resolution, but the developers changed the game to use video mode 13h. This mode does not support page flipping, so the screen updating is less smooth.

MBF in 320x200 runs in mode 13h when page flipping is disabled. When page flipping is enabled it switches to 'unchained VGA mode'.

mr_bigmouth_502 wrote:

Looking back, the hard drive upgrade I did on it was probably to blame, but I was much younger and didn't have as much experience messing with computer hardware. It's a shame I threw that system out.

At that time (486) I did not mess with hardware yet. But did manage to crash the system through software. Fortunately there was a PC tech support department at my dads workplace, to undo whatever had gone wrong.

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 4 of 17, by leileilol

User metadata
Rank l33t++
Rank
l33t++

What about Zdoom? Zdoom is full of assembly and optimization and I recall the Windows version of the 2.x branches ran smoothly, until they went to fmod/fmodex and then the sound system became the heavy bottleneck in later versions. There's also an old 1.x DOS version you should probably try.

also, allegro is slow

apsosig.png
long live PCem

Reply 5 of 17, by Holering

User metadata
leileilol wrote:

What about Zdoom? Zdoom is full of assembly and optimization and I recall the Windows version of the 2.x branches ran smoothly, until they went to fmod/fmodex and then the sound system became the heavy bottleneck in later versions. There's also an old 1.x DOS version you should probably try.

Really?! I think zdoom is probably the best source port considering the community behind it (crazy amount of wads and advanced features). I like "Knee Deep in Zdoom" wad, but I think you need a pentium 3?

Reply 6 of 17, by leileilol

User metadata
Rank l33t++
Rank
l33t++

to be honest, I really don't want to consdier its community. Most just use it to make some dynamic light shitting guns that 'require' gzdoom, and brutal doom wannabes (and brutal doom sucks)

apsosig.png
long live PCem

Reply 7 of 17, by gerwin

User metadata
Rank l33t
Rank
l33t

For windows I have long converted to (G)Zdoom. The DOS 1.17c version is not such an easy choice though.
Summarized:
- One of the few that does not rely on Allegro 3. Uses Midas sound system. Music is not functional in DOS.
- Setup for DJGPP, but won't compile as-is because of the state of the OpenPTC display library.
- Got it to hang in E1M1 after walking around a little. The next start it crashed to DOS while in E1M1.
- Does not play original demos. The primitive '-devparm' framerate indicator is not sufficient for benchmarking.
- I don't think it uses graphics mode X (cause mode X occasionally shows a few blinking pixels on my cirrus logic card).

The package did point out the existence of README.asm which seems to hold the original DOS procedures 'R_DrawColumn' and 'R_DrawSpan'. For what it is worth.
Actually MBF also uses these particular procedures in the form of assembly, but differently (and in AT&T Syntax of course, for DJGPP).

Last edited by gerwin on 2014-09-11, 23:38. Edited 1 time in total.

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 8 of 17, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie
gerwin wrote:
I read that Heretic uses the same 320x200 resolution, but the developers changed the game to use video mode 13h. This mode does […]
Show full quote
mr_bigmouth_502 wrote:

Strangely, I remember it ran Heretic OK

I read that Heretic uses the same 320x200 resolution, but the developers changed the game to use video mode 13h. This mode does not support page flipping, so the screen updating is less smooth.

MBF in 320x200 runs in mode 13h when page flipping is disabled. When page flipping is enabled it switches to 'unchained VGA mode'.

mr_bigmouth_502 wrote:

Looking back, the hard drive upgrade I did on it was probably to blame, but I was much younger and didn't have as much experience messing with computer hardware. It's a shame I threw that system out.

At that time (486) I did not mess with hardware yet. But did manage to crash the system through software. Fortunately there was a PC tech support department at my dads workplace, to undo whatever had gone wrong.

I got rid of that system about 6 years ago. I thought I was "all that" when it came to my knowledge of older systems, but I had a lot to learn.

leileilol wrote:

to be honest, I really don't want to consdier its community. Most just use it to make some dynamic light shitting guns that 'require' gzdoom, and brutal doom wannabes (and brutal doom sucks)

Brutal Doom was fun for about 10 minutes, but it just doesn't feel like "Doom", nor do most TCs for ZDoom. I used to really like Skulltag back when it was still being actively developed, but when that schism developed in the community, and the project continued as Zandronum, I lost interest. It just happened that the parts of it I actually liked were all developed by Carnevil. There was also a short period of time where I enjoyed Zdaemon, and the default maps and game modes felt more like vanilla Doom, though I quickly grew bored of it due to the lack of variety.

Reply 10 of 17, by ColdBrain

User metadata
Rank Newbie
Rank
Newbie

I got flamed in another forum when I said the new Doom borrowing stuff from Brutal Doom was bad because it wasn't what Doom was about.

Brutal Doom is a cool mod, and I like it for what it is, but it's simply not Doom. It's more like a "Mortal Kombat meets Doom" experiment, where the gore and comedy of Mortal Kombat are incorporated into Doom.

Reply 11 of 17, by gerwin

User metadata
Rank l33t
Rank
l33t

Past days I messed with the MBF source a little more.
- It can now compile with GCC 4, then tried and benchmarked different compiler options.
- Introduced a system that checks wheter the statusbar needs to be redrawn in video memory, to save some unnecessary transfers.
Framerate did get a little better, it is 15% over the original MBF. Now actually runs kinda OK on cx5x86:

Benchmark Doom 1 "- timedemo demo3" (E3M5), with 1 level of green border and sound+music:
System: Cx5x86-100MHz (LSSER FP_FAST BTB), 256kB L2, 16MB RAM 60ns, CL5428 VLB graphics
For the source ports: Translucency disabled, Vsync is always disabled in timedemo mode.

Doom 1.9 original   42,2 FPS (Draws directly to mode-X video memory)
MBF 2.04B* 36,4 FPS (Memory buffer to mode 13h video memory)
MBF 2.04B* 30,9 FPS (Memory buffer to mode-X video memory (2 flipped pages))
MBF 2.03 31,7 FPS (Memory buffer to mode 13h video memory)
BOOM v2.02 33,7 FPS (Same as MBF 2.03, I suppose..)

That planar drawing system of mode-X is now clear to me. MBF has only one drawing routine that translates to planar, Original doom is supposedly full of these translations to planar. It is understandable no one ever bothered to re-implement this.
Shawn Hargreaves, the author of the original Allegro, had this to say about it:

Source
If your engine is based around blitting a buffer from system ram to video memory, it would be much faster in mode 13h. Quite apart from having to alter the plane registers, the planar video organisation wreaks havoc with your bus transfer rate (you can't read/write adjacent strips of four pixels with 32 bit instructions if they are scattered all over the place), and most modern cards can accept data a lot faster in linear modes (on my Matrox, blitting to a VBE 2.0 linear framebuffer 320x200 mode is nearly 20% faster than the same resolution in mode 13h, and over twice as fast as in mode-X).

IMHO, mode-X only shines when you are doing all your rendering directly into video memory, and you are able to make use of the write planes to copy groups of four pixels simultaneously (ie. you are doing lots of solid-color fills, or you can fit all your sprites in an offscreen area of video RAM and copy them from there). It was essential on a 386 and well worth using on a 486, but on a pentium you'll almost certainly get better results from mode 13h, or best of all a VBE2.0 linear framebuffer mode...

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 12 of 17, by King_Corduroy

User metadata
Rank Oldbie
Rank
Oldbie

After finding a boxed copy of Ultimate Doom I went and installed it on my Pentium 1 machine. I can tell you playing it on a real machine vs the source ports is WAAAAAAY better. Mainly because you cannot change the level of darkness or many other options that you can in the source port engines. I actually found myself getting into it and actually feeling a bit tense at times 🤣.

Check me out at Transcendental Airwaves on Youtube! Fast-food sucks!

Reply 14 of 17, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie
ColdBrain wrote:

I got flamed in another forum when I said the new Doom borrowing stuff from Brutal Doom was bad because it wasn't what Doom was about.

Brutal Doom is a cool mod, and I like it for what it is, but it's simply not Doom. It's more like a "Mortal Kombat meets Doom" experiment, where the gore and comedy of Mortal Kombat are incorporated into Doom.

That's what I think as well. It's a decent enough mod, but it just doesn't feel like Doom. The main thing that actually disappointed me about it is that they changed some of the monster sounds to give them speech. They're supposed to sound like evil, demonically-possessed, inhuman creatures, not like some little kid's idea of what "bad guys" sound like. 🤣

Reply 15 of 17, by King_Corduroy

User metadata
Rank Oldbie
Rank
Oldbie
leileilol wrote:

Uh.... press F11. Gamma correction has been implemented since 1.1

Whoops probably should have looked in the manual. 😜

Oh well I like it this way. 🤣

Check me out at Transcendental Airwaves on Youtube! Fast-food sucks!

Reply 16 of 17, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie

Lately I've been playing through The Ultimate Doom using the Chocolate Doom sourceport, and it's pretty awesome. Chocolate Doom is to Doom sourceports what BSNES is to SNES emulators.

Reply 17 of 17, by gerwin

User metadata
Rank l33t
Rank
l33t

Slowly making the gap smaller:

Doom 1.9 original   42,2 FPS (Draws directly to mode-X video memory)
BOOM v2.03* 38,4 FPS (Memory buffer to mode 13h video memory)
MBF v2.04* 36,8 FPS (Memory buffer to mode 13h video memory)

Boom 2.03 is also a modified version. I made it compile on GCC4 and added the improved statusbar redraw system.
Since MBF is quite similar to Boom, maybe it can be brought to 38 FPS too. Boom only supports 320x200 mode 13h, where MBF supports 3 video modes. I suspect the larger overhead in video mode code makes MBF a little slower. Will have to test this with the -noblit and -nodraw parameters.

Edit:
Released it here:
Doom 'MBF' for DOS, Maintenance release 2.04

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul