Doomworld Forums - Interesting feature that never made it into DOOM

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Doom General > Interesting feature that never made it into DOOM

Pages (3): [1] 2 3 »

Author

All times are GMT. The time now is 22:20.

shadow1013
Junior Member

Posts: 228
Registered: 08-10

In the Alpha DOOMs .4-.5 there existed two lumps called colors12 and colors15, and after analyzing the source code of the original utilities to make the DOOM playpal and colormap lumps, it seems obvious that they were originally meant to be for some form of 12bit and 15bit color screen mode, as instead of translating the colors into a different light level using pixels in the palette the two lumps actually held 12 and 15bit pixel values for darkness adjusted calculated according to the DOOM palette

11-11-11 01:09 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Cyanosis
Member

Posts: 648
Registered: 10-10

That's pretty neat, never knew about that.

11-11-11 01:28 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Bucket
ROCK & LOAD
COCK BEEN BLOWED
IN YOUR MOUTH,
MANJUICE EXPLOAD

Posts: 3786
Registered: 01-04

Yeah, I think I remember Id planning to implement a hires mode. There was also going to be support for multiple monitors, I believe.

11-11-11 02:56 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

molehill
Warming Up

Posts: 17
Registered: 06-04

Sorry to hijack the thread but I remember reading somewhere (doom bible?) that doom was going to be like an arcade game with 'points' and lives (the soulsphere was supposed to be a 1up).

I wonder how that would of affected the playing experience.

11-11-11 03:02 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Mithran Denizen
Senior Member

Posts: 1093
Registered: 05-10

Bucket said:
There was also going to be support for multiple monitors, I believe.

If you're referring to what I think you are, versions 1.0 and 1.1 did let you set up 3 networked machines to render the game on multiple monitors, using the -left and -right parameters, though the functionality was dumped in v1.2 for whatever reason. I recently toyed around with this feature through a virtual network in DOSBox. It was kind of shitty without actually having three seperate physical monitors, though, since the FOV looks really awkward if all three windows are being rendered on one screen side-by-side.

Chocolate Doom also enables play with three monitors.

11-11-11 03:24 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Marnetmar
Forum Staple

Posts: 2025
Registered: 09-10

Mithran Denizen said:
If you're referring to what I think you are, versions 1.0 and 1.1 did let you set up 3 networked machines to render the game on multiple monitors, using the -left and -right parameters, though the functionality was dumped in v1.2 for whatever reason. I recently toyed around with this feature through a virtual network in DOSBox. It was kind of shitty without actually having three seperate physical monitors, though, since the FOV looks really awkward if all three windows are being rendered on one screen side-by-side.

Chocolate Doom also enables play with three monitors.

I'm guessing it was dumped due to possible VPO errors?

11-11-11 03:48 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 5999
Registered: 07-00

Nope. I don't think it was intentionally dropped at all. Pretty much all the code is still in the source for the left/right mode. left/right mode has no effect on visplanes, by the way - it's just rendering at a different angle.

The original releases of Doom (1.0, 1.1) had the IPX networking built into doom.exe. Doom 1.2 split this out into an external network driver system (ipxsetup.exe and sersetup.exe). It looks like the left/right feature was unintentionally broken when this happened. The interface structure used to communicate between ipxsetup.exe/doom.exe (doomcom_t) has a field that looks like it was intended to support it, but it's not used.

code:
    // These are related to the 3-display mode,
    //  in which two drones looking left and right
    //  were used to render two additional views
    //  on two additional computers.
    // Probably not operational anymore.
    // 1 = left, 0 = center, -1 = right
    short               angleoffset;

I think that comment was probably added by Bernd Kreimeier before the source release, though. Here's the slightly more terse version from the ipxsetup source:

code:
     short     angleoffset;   // 1 = left, 0 = center, -1 = right

11-11-11 04:05 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 7040
Registered: 07-07

shadow1013 said:
after analyzing the source code of the original utilities to make the DOOM playpal and colormap lumps

Do you have a link to that? I'd be very interested in looking at them...

11-11-11 07:54 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Lite Sparkle
Mini-Member

Posts: 50
Registered: 11-11

The Doom Automap (TAB-key) was orginally going to have a mini-game similiar to Asteroids.

11-11-11 08:15 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

LogicDeLuxe
Member

Posts: 628
Registered: 08-03

Marnetmar said:
I'm guessing it was dumped due to possible VPO errors?

I don't see how. Each screen was rendered by its own PC.

More likely the new modem and network code was the reason. They probably though that this was an unimportant feature, and simply didn't bother.

11-11-11 11:30 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 8661
Registered: 07-06

I hear of this alleged "hires" mode now and then (the last time it was in a thread about cDoom, and this was my find about it: zilch).

Similarly, an alleged EGA mode would be at most possible with a modified PLAYPAL only mapping to 16 colors but all framebuffer processing would have still to be done at the byte level (thus wasting 4 bits per pixel), and screen refreshes would have been nowhere near as fast. The reason? EGA: 4-bit planar graphics. VGA: 8-bit chunky graphics. In layman terms, it means that in VGA you can simply write a single pixel directly where you want it to.

On EGA, you have to write a single bit to 4 very different parts of the screen buffer for altering a single pixel, so unless you are doing 2D operations like tile-based rendering, bit-blitting, scrolling or solid-color filling (which write to several pixels at once), it would be prohibitive to render something like Doom or Wolf3D.

Really, where did this rumor come from? There's absolutely no remnant or hint of such a mode in the Doom source code release, not even a commented out occurence of "hires". Everything is hardcoded to the resolution defined by SCREENWIDTH = 320 and SCREENHEIGHT = 200, and there is no mechanism for scaling static graphics, and no way to change the size of resolution-size dependent buffers but with a recompilation. Also, drawing functions are pretty much specialized to deal with raw byte-sized pixels, they are not parametrizable or "generic" in any way.

I'd like to check out those COLOR12 and COLOR15 lumps myself, but by the sound of it they must probably be 12-bit (4-4-4 RGB) and 15-bit (5-5-5 RGB) versions of the original PLAYPAL, perhaps intended to use Doom on platforms with lower-fidelity RAMDACs. What's their size?

Last edited by Maes on 11-11-11 at 11:39

11-11-11 11:34 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

shadow1013
Junior Member

Posts: 228
Registered: 08-10

Maybe I'm drawing wrong conclusions from the code... but thats what I assumed. The colors12 and colors15 lumps are an array of shorts (NUMLIGHTS+2)*256 words long. (NUMLIGHTS = 32). So it doesn't look like any palette format I've seen. Also remember that although PLAYPAL is stored in 8-8-8 format, it is sent to VGA in 6-6-6, as VGA only supports 6-6-6. And about High-res, there is actually only one reference but they probably abandoned it extremely early. the MAXWIDTH and MAXHEIGHT defines in the r_local.h file. (at least for hexen sources, I don't remember were Kermier put those defines in DOOM, but they're still there). And finally, the utilities are actually extremely cool including a whole bunch of random stuff as multigen and the wadlink program used to link the wads together.

Grab em here: http://www.megaupload.com/?d=SYH5EHX4

Last edited by shadow1013 on 11-11-11 at 12:48

11-11-11 12:42 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 8661
Registered: 07-06

The Alpha v0.4 IWAD has a number of other noteworthy things:

The title palette is in a separate lump called TITLEPAL. It's quite different from the normal palette.
The PLAYPAL lump itself is only 768 bytes in length, implying that the colorization effects were either generated procedurally (I added such a fallback mode in Mocha Doom v1.6, allowing it to generate all standard palette effects from just the first entry of the palette), OR that they are somewhere else. Again, not sure if it's very different from standard Doom's first PLAYPAL entry.
The COLORS12 and COLORS15 lumps look more like the COLORMAP lump in structure, but also packed 12-bit and 15-bit palette data in 16-bit chunks. The catch is that they appear to be encoded in little endian format, as for COLORS15 I see the FF7F sequence a lot, but never FFFF. In both cases there is repetitive similarity every 512 bytes.

Titlepal appearance:

http://img836.imageshack.us/img836/617/lepal.png

The 6-6-6 VGA thing is actually noteworthy: it means that ports such as Chocolate Doom who aim for faithfulness should set the lower 2 bits of each color component to zero, and lose some shades of color if aiming to look more like VGA (no idea if this is currently done).

11-11-11 14:25 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

InsanityBringer
Member

Posts: 403
Registered: 08-07

Maes said:
The Alpha v0.4 IWAD has a number of other noteworthy things:

The PLAYPAL lump itself is only 768 bytes in length, implying that the colorization effects were either generated procedurally (I added such a fallback mode in Mocha Doom v1.6, allowing it to generate all standard palette effects from just the first entry of the palette), OR that they are somewhere else. Again, not sure if it's very different from standard Doom's first PLAYPAL entry.

I don't recall Alpha 0.4 ever having palette flashes though -- you can't get hurt at all, you can't collect items, or anything of the sort. Alpha 0.5 had these features, and the pain/pickup fades were precomputed, but oddly enough not those "fade through white" effects that happen when you begin a new game or go to the next level, heh.

11-11-11 14:41 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 8661
Registered: 07-06

Update: the COLORS15 lump does indeed contain a series of 32 packed palettes in 5-5-5 RGB format, packed in little-endian 16-bit works. They represent the original PLAYPAL faded progressively to darker shades.

Now, I have no clear idea how that was supposed to work. Maybe if an indexed 16-bit display was used (an idea I have considered for Mocha Doom) the original intention might have been to use those extra palette indexes to render actual darker pixels, instead of reusing already existing ones in the standard PLAYPAL through the COLORMAP tables. From a programming standpoint, it would be simply a matter of looking up directly into a different palette LUT and write the 16-bit value you found to the screen, instead of using a LUT to redirect inside the same 256-color palette. This would technically make the display 32*256=8192 color ;-)

Assuming that doing so would be technically trivial on hardware that really supported 16-bit indexed displays, that wouldn't have worked out so well memory-wise when you started considering all those extra tinted palettes: memory usage would skyrocket (14 different base palettes with 32 different shades each. Ouch). Of course, all column drawing functions would need to be rewrote...very ouch.

I haven't decoded the COLORS12 lump yet, but I suspect it's more of the same. They might have targeted some particular platforms that used indexed (or HiColor) displays with those exact color depths...no idea which ones though, and no idea whether they did direct HiColor writes or used an indexing system).

Edit: the COLORS12 lump is indeed what it says: 32 PLAYPAL variations in 4-4-4 packed RGB color, in Little Endian format, and with the BOTTOM byte always being 0xF. So e.g. the first bytes of the file are 0x0F00 -> to big endian -> 0x000F -> discard the F -> r:0 g:0 b:0. Maybe it was was 4-4-4-4 RGBA? :-p

Last edited by Maes on 11-11-11 at 14:59

11-11-11 14:50 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Porsche Monty
Member

Posts: 417
Registered: 06-10

Chocolate Doom definitely emulates vanilla's gamma shift problem, but not sure if that's related to the 5-5-5 rgb stuff.

11-11-11 14:57 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

shadow1013
Junior Member

Posts: 228
Registered: 08-10

COLORS12 and COLORS15 are exactly the same except for the fact that its 4-4-4 and 5-5-5. they are not meant to be indexed palettes, but rather colormap, but for real color screens more likely. I come to this conclusion by the comment next to the definition of lighttable_t in the doom source, which is defined to byte but states: // this could be wider for >8 bit display. This would actually mean that a different screenmode entirely would be used and that PLAYPAL would be completely ignored in this case. Also in the alphas theres a menu option that states "Hi-Colot DAC"

11-11-11 14:58 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 8661
Registered: 07-06

Heh that stuff makes me want to try a superindex/hicolor branch of Mocha ;-) Technically it would be a 13-bit display (it's possible to use up to 16-bit indexed displays in Java, or else simply use an extended palette), which should at least look smoother than crappy 256 without the overhead of full-blown truecolor processing.

No idea how they intended to apply palette or COLORMAP shifting effects though....maybe not at all? By frame post-processing? By real-time palette alterations (plausible, if you apply tinting to the palette before rendering a frame, and then revert to a "clean copy" once the effect is over)? Or combining some of both, e.g. both COLORMAP remapping for some effects and super-palette luminosity mapping?

Last edited by Maes on 11-11-11 at 15:12

11-11-11 15:05 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 7040
Registered: 07-07

Maes said:
The 6-6-6 VGA thing is actually noteworthy: it means that ports such as Chocolate Doom who aim for faithfulness should set the lower 2 bits of each color component to zero, and lose some shades of color if aiming to look more like VGA (no idea if this is currently done).

Not to 0; that'd just make everything slightly darker.

You want to emulate VGA, so you trim your channels to 6 bits. But then you have to do the inverse operation since the hardware/libraries actually expects 8-bit values. So how do you make sure that a 6-bit channel value is blown to 8-bit as accurately as possible? Copy the first two bits over the last two. That way, the maximum remains the maximum.

11-11-11 15:22 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

shadow1013
Junior Member

Posts: 228
Registered: 08-10

well in the doom source it just shifted right by two.. so I guess Gez's idea makes since

11-11-11 15:32 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

shadow1013
Junior Member

Posts: 228
Registered: 08-10

I have a feeling when the color12 and color15 lumps were used they intended to completely ignore the colormap lump and probably do frame post-processing to get the palette effects such as pickup and pain color shifts

11-11-11 15:33 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 8661
Registered: 07-06

shadow1013 said:
I have a feeling when the color12 and color15 lumps were used they intended to completely ignore the colormap lump and probably do frame post-processing to get the palette effects such as pickup and pain color shifts

That would have been just too much of an overhead to do pixel-per-pixel back then, as it is today (just take a look at the performance of ports like DelphiDoom (with the experimental 32-bit software renderer) or _bruce_'s true colour Choco Doom fork.

Manipulating/real-time tinting just the palettes and letting the display handle the rest would make more sense (less bytes to process compared to the screen buffer, even more so for higher resolutions as the framebuffer:colors15/colors12 ratio would grow).

But yeah, the palette effects seem thrown in almost as an afterthought/totally new feature after v0.4, perhaps after realizing that a HiColor display would've been too troublesome or too slow for the average system of the time to process. Another problem would be that not all plain VGA (not SVGA) cards of the time supported a HiColor mode, 555 or otherwise, so they had to cut it down to a common minimum denominator: plain VGA without even frills such as ModeX and 320:240 resolutions.

As a sidenote, it's interesting to note that that the 5-5-5 RGB mode was common on SVGA and some advanced VGA cards of the time, while the NeXTStations apparently had a native 12-bit 4-4-4 RGB mode (with 4-bit alpha channel so actually 4-4-4-4 ARGB, hence the weird format I encountered in the COLORS12 lump).

11-11-11 15:48 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 7040
Registered: 07-07

Oh, and thanks for the dmutils pack! That's very interesting stuff.

unfuck.c is the best program.

11-11-11 16:08 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 8661
Registered: 07-06

Here is what the palettes inside COLORS12 and COLORS15 look like, for whom it might concern:

COLORS15 image pack
COLORS12 image pack

11-11-11 16:10 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

shadow1013
Junior Member

Posts: 228
Registered: 08-10

lol no problem with that! I forget where I found it but Its open source apparently :) and believe it or not, I've actually used unfuck.c several times in my system when shit blows up. dcolors btw shows how all the palettes and colormaps and color12&color15 were generated, so Maes should take a look in there ;) hopefully helps

11-11-11 16:11 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 8661
Registered: 07-06

Yeah, they look worth spending some time over (apparently, the lump compression used in some console ports is defined plainly and clearly in these utilities as well). Too bad I figured out the color stuff myself before I noticed dcolors.c... damn DIP background ;-)

11-11-11 16:14 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

shadow1013
Junior Member

Posts: 228
Registered: 08-10

Honestly what I would like to see most referring to that would be the wadlink.wl used to build the DOOM wads. The Heretic and Hexen ones are available though, but unfortunately only the highest level are. It seems like a much cleaner alternative to building wads then deutex does

11-11-11 16:18 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 7040
Registered: 07-07

Maybe Romero has these .wl files?

So with this pack, and DoomBSP, we have pretty much all the tools Id developed to create Doom; except DoomEd and the Fuzzy Pumper Palette Shop.

Looking at dcolors.c; I see a validation of the values I got from my reverse-engineering work done on the Doom/Heretic/Hexen/Strife palettes when I was basically adding this feature to SLADE 3. But now I have reference for writing a COLORMAP generator as well.

11-11-11 16:27 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

shadow1013
Junior Member

Posts: 228
Registered: 08-10

Yes that is correct :) all we need are the source files DoomEd and FuzzPumperPalettShop and we could make DOOM the way iD did. literally.

And actually I had emailed Romero about getting a development dump of the DOOM source code (not modified by Kermier, and including DoomEd) and unfortunately got this response: :(

Hello,

I'm not sure if i will be able to release the entire DOOM 1/2 dev dump. It's not something that id ever planned on releasing, nor would ever release because of the massive cleanup that would have to occur.

I can check on the idea sometime in the future with Carmack.

Thanks,

John Romero
john@rome.ro
http://rome.ro

11-11-11 16:29 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1740
Registered: 08-03

shadow1013 said:
source code of the original utilities to make the DOOM playpal and colormap lumps

Nice. I didn't know these were released to the wild. They'll definitely prove useful. Cheers.

11-11-11 17:45 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 22:20.

Pages (3): [1] 2 3 »

Doomworld Forums > Classic Doom > Doom General > Interesting feature that never made it into DOOM

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >