Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Foebane72

Why don't source ports REWRITE the entire Doom engine?

Recommended Posts

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?

 

Share this post


Link to post

For the original feel, because many aren't that familiar with render coding and do what they can best.

Share this post


Link to post

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

Share this post


Link to post
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. 

Share this post


Link to post

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 by Loud Silence

Share this post


Link to post
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.

Share this post


Link to post

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).

Share this post


Link to post

speaking of banding can dimisnihng lighting that looks kinda like this be done?

 

8rgedmol8lj31.png

Share this post


Link to post
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.

 

Share this post


Link to post
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.

 

Share this post


Link to post

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)

Share this post


Link to post

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.

 

Share this post


Link to post

 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

Share this post


Link to post

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).

 

 

Share this post


Link to post

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.

 

 

Share this post


Link to post

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:

 

image.png.84da250b979c3b8d876663a33e0a68c5.png

 

 

Boom deep water in 32 bit software rendering with and without external textures:

 

image.png.309db1f34f242168f79d98c7e1559153.png

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×