Doom in true colour [ testers for exe welcome/src snapshot/links updated ]

[_bruce_]

@DaWerecat:
Good catch... the man with the keen eye strikes again - this bothered me too.
A "Saturation Overrides Blending" option will have to be added.

@Gez:
Dang, eight and no more.
Big thanks for your list!
Reading through it as we speak. Starting "fresh" off at the 900+ region seems most convenient. On the other hand, why let the 600-799 region go to waste.
Although the "SonicRoboSomething" project uses around 10 or so linedef numbers starting at 600 - I guess the sonic stuff is an engine mod so this may not be an issue.

@Kaiser
'LIGHTS' lump sounds like a deal.

@kb1
I'm more than joyed to be able to add something to paint(or rather r_draw) Doom's prolonged existence as joyful as possible.
Many of you are clever engineers so I'm more than willing to strain my ears and listen to the accumulated expertise on this very board.


a] I will read through Gez's linedef spec and rethink what would make the most sense to me regarding a few minimalist base types.
b] As stated previously, I favor Kaiser's 'LIGHTS' lump with the extension that also the middle walls can carry unique color/light values.
The dummy byte in the middle/color entry can be used for alpha values regarding transparent middle-linedefs.
I still have to delve into Doom64's specs and rethink this a lot more.


Breezeep: Links are now up again(src/exe)!

[Gez]

kb1 said:

Special map lumps, and the like, require special map editor support, which would be nice...but not as readily adopted.

As far as I'm concerned, I'm okay with adding editing support of special lumps to SLADE 3 if the implementation of said lump is reasonable and straightforward. I do want to eventually make SLADE 3 a full-fledge Doom64 editor so I will have to look at proper support for LIGHTS lump one of these days.

_bruce_ said:

Although the "SonicRoboSomething" project uses around 10 or so linedef numbers starting at 600 - I guess the sonic stuff is an engine mod so this may not be an issue.

Yes, I've refrained from listing the specials in engines like SRB2 and Doom64 EX for three main reasons:
1. These engines are used for their own maps, and their own maps only -- they can't be used to play a normal PC Doom map, and at the moment there are no ports that I'm aware of that support both one of them and the more traditional games (in the same way that ZDoom, Legacy, etc. support both Doom and Heretic for example). So no conflict. Similarly, the Hexen specials aren't listed, because it's a very different map format anyway.
2. The list is already quite long and adding more engines would overload it, making it less legible.
3. Laziness. :p

[cq75]

Just noticed this topic now. I just wanted to say, this is really impressive, great work!

[VGA]

Vulture said:

You might be interested to know that Odamex has a truecolor renderer (that also uncaps the framerate) in development.

https://dl.dropboxusercontent.com/u/72213361/32vs8.png

It is not choco, but pretty close :)

I installed the latest stable Odamex, enabled 32-bit color and the color banding was real. I am disappoint.

EDIT: Why did the "higher resolution thread" get locked? Weird.

[Maes]

VGA said:

I installed the latest stable Odamex, enabled 32-bit color and the color banding was real. I am disappoint.

Out of curiosity, I glanced over the SC (very superficially, I must say) and found a reference to a 32K color mode being actually used, even if the canvas is 32-bit. This is quite probably the same as the dropped Doom Alpha HiColor mode, which still used colormaps for obtaning light effects.

This would make sense, as 32K colors is the "easiest" true color mode to implement, without changing the number of colormaps or tampering with the colomap-remapping system as little as possible: you still use the 32 "traditional" colormaps but rather than them being remappings to the same 256 colors being used over and over, they contain direct RGB data. And if you keep their number at 32, you don't need to change any of the light-shifting formulas used in Doom (Mocha Doom actually does fudge with the formulas to obtain more than 32 colormap), while ChoColor Doom uses a completely different system for recoloring.

In any case, with 32 colormaps you can have at most 8K (8192) distinct colors on-screen, rather than 32K, and yes, banding is still very visible under these conditions, even with the extra colors. The main benefit of this "32k color" mode is that color shifts at low luminosities are practically eliminated (e.g. you don't see orange hues becoming purples anymore), but banding and low-light pop-in are still a problem.

In the Odamex source code there's a reference about using a "32K color" transparency map, rather than an "8k color one", which would give some more colors on screen when transparent objects are present (a nice addition, BTW), but not solve the banding. 32k is also the practical limit where a transparency LUT can be used: an 8k table is taxing enough on the cache, a larger one would be a performance-killer.

Only with more colormaps (which would mean 64, 128 or 256 colormaps) banding ceases being noticeable, which means however that they must be generated by the source port dynamically starting from PLAYPAL (as is done in Mocha Doom) or supplied in an external lump (in that case, they can be non-conventional).

[kb1]

_bruce_ said:

@kb1
I'm more than joyed to be able to add something to paint(or rather r_draw) Doom's prolonged existence as joyful as possible.
Many of you are clever engineers so I'm more than willing to strain my ears and listen to the accumulated expertise on this very board.

There are lots of smart guys here, and your code is not too shabby either, that's for sure. I must admit some bias - I am considering taking a crack at adding 32-bit color to my home port, and, I'd like to be compatible with your implementation.

I like the fact that you've taken it to the next step - Sure, you've got 32-bit color, which is impressive, but you've also got neat sector and thing coloring stuff going on. Awesome.

In my home port, I did a bunch of work with colormaps, and I came up with some options that I haven't seen in other ports yet. I'll list them below, since you are talking about coloring distinct areas, such as mids.

I came up with these distinct abilities:
* Colored light - lite goggles remove colored light effect, otherwise effect is always fullbright. Affects walls, flats, things, and player gun.
* Light filter - lite goggles DO NOT remove light filter effect, which is also always fullbright. Basically used for looking thru colored glass.
* Fog - lite goggles remove fog effect mostly, otherwise fog light is scaled differently than normal. Affects walls, flats, things, and player gun.
* Paint - Colormap is used to "paint" floor and/or ceiling and/or walls, without affecting things, or player gun. Lite goggles DO NOT remove colored light effect, but lower light darkens
* Glow effect: Flats, walls, and things. Certain pixel colors can be set fullbright, with a special colormap, with no performance loss normally associated with brightmap lookup implementations. Bright pixels follow the above lighting rules, so they are affected by light filter and fog, but not colored light, or painted areas.
* Wall Splats: Also follow color, filter, and fog rules, and can be made fullbright, colored, or with glowing pixels.

I think I went overboard, but it's kinda neat to see. I'll try to upload some screenshots soon. I mention these to give you something to think about when you are deciding how many fields you'll need. Making all of these methods work in 32-bit color has been a frightening idea, for me, for a while now, but your port is providing a lot of motivation! As always, good luck.

Gez said:

As far as I'm concerned, I'm okay with adding editing support of special lumps to SLADE 3 if the implementation of said lump is reasonable and straightforward. I do want to eventually make SLADE 3 a full-fledged Doom64 editor so I will have to look at proper support for LIGHTS lump one of these days.

That will make the difference. Once there's tool support, people will start trying to use it! And, then there's some pressure for other source ports to join in, which is a win-win.

VGA said:

I installed the latest stable Odamex, enabled 32-bit color and the color banding was real. I am disappoint.

I do not see color banding in that screenshot. In fact, the room is too bright to see shadowing at all, to me. Do you mean the different shades on the far wall? Those walls are angled differently. Arguably, a nice "smooth fake contrast" algorithm like ZDoom's *should* shade those walls a bit. But, banding? I'm not seeing it. The colors in the 32-bit image do look very rich - see the pinkies. They're pink!

[viti95]

On 11/4/2011 at 5:29 PM, _bruce_ said:

Floor standard


Floor fixed


If I had known that it's changing a line of code and 2 variables I would have done it sooner. Jaguar Doom uses the more accurate version.

 

Sorry for necrobumping this, but I'm having this same issue in FastDoom on HighRes modes. How did you fixed it? Thanks!

[Julia Nechaevskaya]

As far as I recall, this will require one of these corrections, but I can't remember which one exactly. Here they are in Crispy Doom, may be handy: this and this.