Foebane72 Posted October 27, 2019 Doom is a great game and not a bad first id Tech, but ever since I played the first source ports, I wonder why they didn't ditch the severely restricting "light diminishing" effect in just 256 colours? Or in fact, just ditch that 256 colour limit altogether and use high- or even true-colour for the light diminishing? The thing about the light diminishing is it ruins the look of the game, where the different brightness levels as you go off into the distance show up as these ugly "bands", and in especially dark areas, it can move from black to rather bright in one go. Rewriting the engine to use more colours would make the game look less dated. Yes, the source ports use DirectX or OpenGL high- or true-colour for special effects that were not in the originals, but the 256-colour core is still there. So why not rewrite the entire render core? 0 Share this post Link to post
MadGuy Posted October 27, 2019 For the original feel, because many aren't that familiar with render coding and do what they can best. 1 Share this post Link to post
StalkerZHS Posted October 27, 2019 i mean, that diminishing light thing gets disabled when you use openGL 2 Share this post Link to post
Gez Posted October 27, 2019 Because: The point of Doom ports is to play Doom. If you change things too much, people complain that it's not Doom anymore. Most people don't agree that light diminishing ruins the game. To the contrary, it's a defining part of Doom's unique aesthetics and levels are designed to look good with it. Rewriting the entire engine is actually a lot of work, and definitely not something that any sane developer would want to do in one go. 15 Share this post Link to post
MadGuy Posted October 27, 2019 Oh that one. You can even remove it if you toy around with the lighting constants. You can check Classic RBDOOM if you want to see how it looks like 0 Share this post Link to post
Chopkinsca Posted October 27, 2019 1 hour ago, Foebane72 said: The thing about the light diminishing is it ruins the look of the game, where the different brightness levels as you go off into the distance show up as these ugly "bands" That is just an opinion. I like the look of the original game. 6 Share this post Link to post
Loud Silence Posted October 27, 2019 (edited) I love original Doom's graphics. Resolutions i play on are 320x200 and 640x400 (Software Renderer), picture gets correctly stretched on 1024x768 screen. If you have trouble with Doom's light diminishing, try TES Arena and go to dark dungeon (BTW i love that game too). That's how these games were made and it must be respected. Edited October 27, 2019 by Loud Silence 3 Share this post Link to post
Doomkid Posted October 27, 2019 (edited) Quote I wonder why they didn't ditch the severely restricting "light diminishing" effect in just 256 colours? Or in fact, just ditch that 256 colour limit altogether and use high- or even true-colour for the light diminishing? My dude, you really need to try GZDoom, or Odamex in 32b color mode if you prefer a more oldschool port. GZDoom and Odamex in high-color remove the diminishing bands of light to make them smoother, displaying a gradient of shades well beyond what the vanilla engine offers. 1 Share this post Link to post
Noiser Posted October 27, 2019 The original light diminishing is what makes the game so unique and appealing for me. I love how some colors changes like if there some sort of fog. The pink-to-brown in special makes some really grungy and disgusting scenes that are lost without the limit. 17 Share this post Link to post
seed Posted October 27, 2019 (edited) Because, like others said, when you change it too much it stops being Doom. It also won't feel like it anymore as the feeling is tied to the engine the game is running on directly. It's also an all-encompassing nightmare to rewrite an engine completely, if it was truly worth it, it would have probably been done by someone at this point. Also the SW banding, plus the light diminishing effect is an integral part of Doom, whether you like that or not is purely subjective (I personally do), but if you don't, GZDoom has 2 Truecolor SW renderers at your disposal, and GL renderers remove the effect completely anyway (GZDoom can also emulate it in GL for a pseudo-Software look though). 2 Share this post Link to post
jeroa Posted October 27, 2019 speaking of banding can dimisnihng lighting that looks kinda like this be done? 3 Share this post Link to post
Graf Zahl Posted October 27, 2019 4 hours ago, Foebane72 said: So why not rewrite the entire render core? Uh... What do you think every single hardware rendering port has done? Over the last 20 years there have been multiple attemts - some were successful, others not so much and some even persisted despite not being that great to begin with. 5 Share this post Link to post
Cruduxy Pegg Posted October 28, 2019 Because it is a full time job for no money. 2 Share this post Link to post
Foebane72 Posted October 28, 2019 13 hours ago, StalkerZHS said: i mean, that diminishing light thing gets disabled when you use openGL 11 hours ago, Doomkid said: My dude, you really need to try GZDoom, or Odamex in 32b color mode if you prefer a more oldschool port. GZDoom and Odamex in high-color remove the diminishing bands of light to make them smoother, displaying a gradient of shades well beyond what the vanilla engine offers. Thank you, that's all I needed to know. Doesn't Zandronum do it as well? That's my SP of choice. 1 Share this post Link to post
Doomkid Posted October 28, 2019 It sure does, as long as you run it in openGL. In software mode it still has the banding though, it would be really cool if there was a 32bit color mode for software but that isn't a feature right now unfortunately (I think it's probably too niche of a request) 0 Share this post Link to post
Graf Zahl Posted October 28, 2019 GZDoom has a 32 bit software renderer, the main problem with it is performance - doing this kind of thing isn't anything modern CPUs have been optimized for. 0 Share this post Link to post
drfrag Posted October 28, 2019 It's in since long ago and performance was good AFAIR, it's in LZDoom and even the original version in ZDoom32. BTW a guy is actually rewriting the entire engine from scratch, i don't know how far he will get. https://twitter.com/doomreboot 1 Share this post Link to post
wesleyjohnson Posted November 8, 2019 (edited) Ports with 32 bit software draw, like DoomLegacy, have already done much to improve software draw. However, in DoomLegacy, the 32 bit software draw still goes through the ds_colormap, because everything in Doom about how the colors are affected by distance, is defined by those color tables. Also that is how colormaps are done. Where the 32 bit RGB draw has it most impressive advantage is in translucent and fuzz. Instead of using those palette color translucent tables, which were far worse than the distance banding, the 32 bit software draw can use true RGB blending, which is what is in DoomLegacy 32 bit drawmode. Back to the colormaps. I have tried to analyze the Boom colormap for LAVA, so that it can be rendered using RGB blending. That colormap is highly non-linear, and our simple linear blending effect does not truly replace it. This is one area where the palette draw still renders better than the 32 bit RGB draw (which includes OpenGL too). 0 Share this post Link to post
Graf Zahl Posted November 8, 2019 Boom's watermap is also interesting but not quite as extreme as the lava. And since ZDoom has been replacing it with a simple color blend from the earliest days it's not really that well known anymore. I guess if it changed now I'd get more complaints than praise for the decision. For such extreme colormaps there isn't really much that can be done. The easy part would be to create a translated texture for the actual rendering, but then deriving a working blend formula is a different matter. It's not impossible, if you can calculate a blend factor and a fade color per level they could be interpolated by the shader (without a shader such a thing is actually impossible to process, though.) If this was the Build engine where palette manipulations are a lot more commonplace than in Doom it would probably be worth doing - actually it would be an essential part of getting the engine right -, but as things stand, the demand for supporting them in hardware rendering for Doom has not been high - in the whole time I've been working on GZDoom there hasn't been a single feature request for it. If I wanted I could add this in GZDoom with very little overhead because all the infrastructure for palette translations is already there and could easily be switched on for handling colormaps as well as palette translations for sprites. The downside, of course, is that it'd degrade true color textures and increase the resource load on the GPU quite significantly. 0 Share this post Link to post
jval Posted November 8, 2019 In DelphiDoom there is an option at 32 bit software rendering that emulates colomaps. For Boom effects like 242 deep water I calculate the difference that the custom colormap does for each standard palette entries, and then calculate the 32bit texture (dc_source & ds_source equivalents of the clasic 8 bit renderer) applying to the source the difference that the colormap makes to it's nearest palette entry. During the process the 32bit source texture is reduced to 15 bits depth (for performance and memory usage purposes). Spoiler Colormap emulation in software rendering: Boom deep water in 32 bit software rendering with and without external textures: 0 Share this post Link to post