Things about Doom you just found out

[ABRACADABRA]

I just found about DOOMWADDIR environmental variable. all these years of playing doom I have a couple of IWADs scattered in source ports folders or instead a mess of files in one folder with all ports installed in one directory. what a shame -_-

[Linguica]

Here's something a little odd: we all know that the Doom palette is made up of 256 colors, right? And each color is a 24-bit RGB value, with 8 bits per color.

Well, VGA hardware only supported *6* bits per color, so the range was 0-63 instead of 0-255. That meant that when Doom sent the palette data to the VGA hardware, the 2 least significant bits were truncated from each.

Whoever picked out the precise Doom palette must have known about this, because each of the RGB values are 4 apart - 7, 11, 15, etc. So nothing was lost when it was passed to the VGA hardware, because it had been designed with this in mind.

However, all of the other palettes for pain, picking up items, etc - as well as all the color values when gamma correction was enabled - were generated assuming that the full 8-bit range was available. This meant that there was a loss of precision when it was passed to the VGA hardware, and the colors ended up looking ever so slightly off.

[kb1]

Linguica said:

I find it hard to believe that PrBoom et al haven't solved this problem? I've never noticed lighting changes at different resolutions.

Yeah, I think maybe that's why it hasn't been fixed: Lighting "works", the issue is not really massively noticeable, unless you switch res OCD-style...

Linguica said:

In any event, my initial spitball would be to change the wall lighting algorithm from using rw_scale, which is dependent on resolution, to rw_distance, which isn't. rw_distance is inversely related to rw_scale so you would need a LUT or something to do it. (Or, gee, we already have a LUT for determining light levels at different distances...)

I looked at PrBoom briefly and saw they had spun off a separate function for determining the proper colormap, and it included this:
...
Which is like, come the fuck on, I don't want to decipher this.

Yeah, that's not nice to look at. I guess I'll add this to my list of to-dos.

[TwinBeast]

After your findings, I decided to take some screenshots of Chocolate-Doom in windowed mode and the colors were added to 0 in 4 steps, up to 252.

Then I took some screenshots from DOSBox, and also saved screenshots with DOSBox.. and noticed it does this for the palettes: 0 to 60 in 4 steps, 65 to 125 in 4 steps, 130 to 190 in 4 steps, 195 to 255 in 4 steps.

And Id palettes seem to be 4 steps subtracted from 255.

Now I just wonder how DOS actually displayed the VGA colors...

[Linguica]

Well, Chocolate Doom purposely degrades the palette to a 6-bit representation so it will appear like it did on VGA hardware, so all the colors end up as multiples of 4. I guess the result is that pure white is displayed as (252,252,252) instead of (255,255,255). But that's not really a bug per se, since it's simulating an entirely different kind of display hardware than the true-color stuff we all have now. Like, I guess the brightest color it displays is a little less bright than what our current hardware is able to do. But if you added 3 to all of the colors, then pure black would be (3,3,3)... so what are you gonna do.

I looked at the other Doom-game palettes and I noticed there's at least one instance where it would make a genuine difference: in Heretic, there are two colors in the palette of (216,216,216) and (219,219,219). Even though these look like different colors to us, VGA hardware would change them both to (54,54,54).

[Koko Ricky]

Vanilla Doom doesn't display pure white or black?

[Linguica]

Sure it does, but VGA hardware output an analog signal so it's not directly comparable to a digital RGB level. Like... an old-style CRT displays an analog VGA signal directly, but a modern LCD panel has to convert it to a digital signal, so it depends on the conversion circuitry in the display, which determines what the final colors displayed are.

Moreover, think of it like this: if you want to set 0 as pure black and 63 as pure white in a VGA signal, and 0 / 255 as black and white in normal 24-bit true color, then you have 62 gray levels in a VGA signal and 254 grays in true color. 254 isn't a multiple of 62, so the conversion can't be perfect.

[LigH]

Linguica said:

Well, VGA hardware only supported *6* bits per color, so the range was 0-63 instead of 0-255.

Depends. Original VGA cards may have used a RAMDAC with 6 bit resolution, supporting 262,144 possible values; but many SuperVGA adaptions, especially those supporting TrueColor video modes, early implemented RAMDACs with 8 bit resolution. The VESA VBE extension to the VGA BIOS will report the RAMDAC depth.

[Linguica]

LigH said:

Depends. Original VGA cards may have used a RAMDAC with 6 bit resolution, supporting 262,144 possible values; but many SuperVGA adaptions, especially those supporting TrueColor video modes, early implemented RAMDACs with 8 bit resolution. The VESA VBE extension to the VGA BIOS will report the RAMDAC depth.

OK, but did that carry over how how the original (DOS) Doom was displayed on those cards? If that's so (or not), you should post in the Chocolate Doom thread and make a case for why automatically degrading to an 18-bit palette is right or wrong.

Googling it, I found a page that says the following

This created a small compatibility problem: during loading the LUT, the original VGA RAMDAC expects 6-bit values aligned at least significant position in a byte. When the RAMDAC is switched to 8-bit mode, the values loaded are 8 bits wide, and their format is not compatible with the 6-bit one. Due to compatibility reasons, the contemporary RAMDACs must handle 6-bit primaries in "old" manner. And this duality must be correctly handled by the programmer.

Also, from looking into it, it seems like in normal old-school VGA programming you end up passing a 6-bit value directly, which suggests that Doom would have handled that portion already; since we don't have the real DOS Doom source code we don't exactly know how the low-level stuff was handled AFAIK. Maybe someone has analyzed the binary to gain some insight?

[LigH]

ChocolateDoom is probably still correct. The generic VGA BIOS functions to manipulate RAMDAC palette registers (without VESA VBE) used only the 6 lsb in the CPU registers or buffer.

INT 10h

AH=10h
AL=10h (set single RAMDAC palette entry)
BX=entry (palette entry number)
CH=green (6 bit)
CL=blue (6 bit)
DH=red (6 bit)

AH=10h
AL=12h (set RAMDAC palette range)
BX=offset (number of first palette entry to change)
CX=count (how many palette entries)
ES=BufSegment
DX=BufOffset

To change the palette comfortably with 8 bit depth and during the vertical retrace (without tearing), you would have to use the VBE 1.2 / 2.0 functions:

AH=4Fh
AL=08h (RAMDAC palette control; VBE 1.2+)
BL=00h (set RAMDAC resolution)
BH=bits (usually 6 or 8)

This ^ would probably also enable 8 bit resolution for VGA BIOS functions, being handled by the VESA BIOS extension too.

AH=4Fh (VBE functions)
AL=09h (set RAMDAC palette range; VBE 2.0+)
BL=00h (set palette; +80h = during VRet)
CX=count (how many palette entries)
DX=offset (number of first palette entry to change)
ES=BufSegment
DI=BufOffset

[jeff-d]

Linguica said (very long time ago!):
While thinking about Doom lighting, I wondered how exactly the Doom engine calculates which light level to show.


I'm not sure this has ever really been changed in a software port. I do know that Maes messed with these values for his true-color Java port, but that's a little different.

My port has had this in since at least 2002, and possibly even 1998!
I cannot remember now which port I copied it from, but it would have been one of the RiscOS ones.

[Linguica]

jeff-d said:

My port has had this in since at least 2002, and possibly even 1998!
I cannot remember now which port I copied it from, but it would have been one of the RiscOS ones.

Yeah, but you RISC guys are a different breed :P

In other news, Romero claims that the id designers never ran into a visplane overflow when making Doom levels.

[snapshot]

DOOM's engine Is a 2D engine .. (i'm serious)

[scifista42]

DMGUYDZ64 said:

DOOM's engine Is a 2D engine .. (i'm serious)

It's not a true 2D engine at all. Game objects move around in 3 dimensions.
It's not a true 3D engine either. You can't have floor over floor, etc.
It's classified as 2.5D engine. (but the page only mentions Doom under the chapter "Billboarding")

[Doomkid]

Linguica said:

In other news, Romero claims that the id designers never ran into a visplane overflow when making Doom levels.

I could have sworn the .99 shareware did a VPO on e1m8 from certain distant angles, but maybe it's the drugs talking.

[Koko Ricky]

It did a HOM but not a VPO.

[Linguica]

In a way it's too bad they didn't. If Romero had a level VPOing, Carmack probably would have raised the limit, if not removed it entirely.

[Dragonsbrethren]

Doomkid said:

I could have sworn the .99 shareware did a VPO on e1m8 from certain distant angles, but maybe it's the drugs talking.

Drawsegs overflow, not visplane.

They did raise the limit for Doom 2, so someone must have at least anticipated it being an issue.

[Krazov]

GoatLord said:

It did a HOM but not a VPO.

I imagined that post sang to the melody of “I shot a sheriff, but I did not shoot the deputy.”

[scifista42]

Krazov said:

I imagined that post sang to the melody of “I shot a sheriff, but I did not shoot the deputy.”

Drawsegs overflow only results in a temporary HOM, usually in a distance. Visplane overflow crashes the vanilla exe immediately.

[40oz]

Usually when modeling a map after existing vanilla maps, being more conscious of the design of the layout and the shapes of rooms rather than details, I rarely exceed 60 visplanes. I feel like 128 is pretty generous if it wasn't expected that custom doom levels would exceed the quality of the initial game.

[scifista42]

40oz said:

I feel like 128 is pretty generous if it wasn't expected that custom doom levels would exceed the quality of the initial game.

(Un)Fortunately, it is expected. :) Or at least the mappers sometimes just want to create unlimited impressive architecture.

[Gez]

Linguica said:

Well, Chocolate Doom purposely degrades the palette to a 6-bit representation so it will appear like it did on VGA hardware, so all the colors end up as multiples of 4. I guess the result is that pure white is displayed as (252,252,252) instead of (255,255,255). But that's not really a bug per se, since it's simulating an entirely different kind of display hardware than the true-color stuff we all have now. Like, I guess the brightest color it displays is a little less bright than what our current hardware is able to do. But if you added 3 to all of the colors, then pure black would be (3,3,3)... so what are you gonna do.

What I do when converting 6-bit-per-channel colors to 8-bpc colors is to take the two most significant bits and add them back as least significant bits, so "abcdef" becomes "abcdefab".

63 : 111111b => 11111111b : 255
0 : 000000b => 00000000b : 0

[The_MártonJános]

Not now, but I'm still prone to be surprised at that the initial room in MAP05 is an outdoors one.

Also, the "exit door locked by a yellow key which is located in the room just before and is the third [and ofc last] key in the level and you must raise a bridge to access this exit door" is a running trend on MAP04-05-06.

[scifista42]

Unlike other Doom / Doom 2 mappers, American McGee's maps in Doom 2 never use the standard EXITDOOR for an exit room, except MAP22 (which is a hellish map, so that the door doesn't really fit).

[ABRACADABRA]

Cell said:

Not now, but I'm still prone to be surprised at that the initial room in MAP05 is an outdoors one.

I always knew that, but I'm just found that second room IS indoor one. always thought both of em outdoors!

also not actually about doom, but I'am just found that I NEVER get the golden key before the nailgun in e1m3 in quake. I mean every single time I plaayed it I followed the route, shown in the first demo! Yeah, sometimes I killed ogress from the right, but I never to this day seen a peple, that takes another route and not jumping from the bridge to the key


and also, thing that I not just found, but when I first time played doom and entered the teleporter in e1m8, I thought there was a massive crowds of monsters eating me to death in that dark field

[Linguica]

If Doom had had a better PRNG, the respawn times for enemies in Nightmare or -respawn mode would have had a median of almost exactly 45 seconds, and a mean of almost exactly 60 seconds. As it is, the times are a little less (38 and 50, respectively).

[The_MártonJános]

ABRACADABRA said:

and also, thing that I not just found, but when I first time played doom and entered the teleporter in e1m8, I thought there was a massive crowds of monsters eating me to death in that dark field

I guess that was they wanted you to believe.

[Platinum Shell]

Cell said:

I guess that was they wanted you to believe.

Worked pretty damn well. When I was little, I thought there was a full on area to explore there in the darkness, and that skilled players could kill them all and then do as they please. Once I finally did do just the such (along with IDBEHOLDL) I was super saddened to learn it was just a dinky little room.

[_bruce_]

Gez said:

What I do when converting 6-bit-per-channel colors to 8-bpc colors is to take the two most significant bits and add them back as least significant bits, so "abcdef" becomes "abcdefab".

63 : 111111b => 11111111b : 255
0 : 000000b => 00000000b : 0

Interesting - what's the premise behind this?