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

What is the best doom engine? (& why)

Recommended Posts

MasterOFDeath said:

Where's doom3d


You mean Fudgefactors Doom3D port? That was promising, I used its D3D rendering as a base of my toy minidoom engine. Too bad it seems dead now for good.

Share this post


Link to post

I vote for ZDoom/GZDoom/Skulltag. The reality is that these ports really are *extremely* similar in many aspects. I would recommend Skulltag for multiplayer. The reasons being that it works with almost any wad in a variety of game modes online. Survival Co-op is great when played on some crazy wads originally designed for single player GZDoom.

For single player however there's no question that ZDoom and GZDoom definitely give you the most up to date features, not to mention that the source code is freely available for these 2 ports which is a huge plus.

Share this post


Link to post

What the hell kind of poll is this?

I use Chocolate Doom 90% of the time, the rest of the time it's PrBoom+

Share this post


Link to post

GZDoom - totally new school, tons of great features, can play just about anything
PRBoom-Plus - perfect mixture of old school and new school
Chocolate Doom - totally old school; great for that warm, fuzzy, nostalgic feeling.

Share this post


Link to post
Nuxius said:

GZDoom - totally new school, tons of great features, can play just about anything
PRBoom-Plus - perfect mixture of old school and new school
Chocolate Doom - totally old school; great for that warm, fuzzy, nostalgic feeling.


Almost the same for me, I also like Risen3D a bit

Prboom-plus is amazing like it but some fails like the in the menu skull
cursor that move by itself or when I move the mouse.
and when I exit games It still have that old bug that switches all
my icons. And it use a ton of library too.

Gzdoom is the best IMO, I still hope It will get some new openGL
features like zdoomGL or doomsday have someday (hq2x,3x,4x ,textures contrast settings,blending animation for water,detail textures...)

the only thing I hate in openGL rendering is that contrast setting
I can't set color sector intensity because when I increase contrast
I cant help for the darkness and it look jerky

The best port of Doom will have to include features console port of doom, because they have sense maybe Doom64 EX based on doom3D.

Share this post


Link to post
printz said:

because I can't stand the blurred pixelation (why do 3d hardware engines fear pixelation so much that they blur it?) and the sprites' cardboard rendering. They also look bad if they're always aligned to player's view and seen from above.

The 3d engine also darkens the environment, though I'm sure that's fixable, and that it's also hardware's fault.

That's where the setup comes in handy. I don't like Doom's textures blurred either, so I just turn that feature off in the rendering setup. Of course, the brightness can be adjusted as well. What remains is an image with pixelated textures as the creators had in mind, but without all those 8 bit quantized lightning ugliness. And effects can even use colors which are not in the palette at all, most notably cyan.

The engines I usually use are PrBoom, Choclate Doom, and GZDoom. All of them have their own strength I don't want to miss. Sometimes, I also use Risen3D with highres textures, costum music and polygon things. And due to lack of maps made for, most of the other engines are rarely used, but still there to be used now and then.

I don't think that there is a "best" engine. It depends much on best for what. Compatibility for old maps, playability on weaker hardware, support for many extra map features, enhanced network playmodes, demo compatibility, lots of eye candy etc.. There might be situations where you even would prefer using the original vanilla exe, for instance running Doom on a 486 DOS PC and want to watch a lmp made for Doom 1.666.

Share this post


Link to post

LogicDeLuxe said:
What remains is an image with pixelated textures as the creators had in mind, but without all those 8 bit quantized lightning ugliness.

The problem with removing those lines is that light diminishing is much less noticeable, giving a bare feel, and in the end developers have to fiddle with it, either allowing something where the light diminishes at something like the original rate, or at a different rate that gives a visual impression that is closer to Doom's method. The lines also enhance the impression of movement, when they move with you. I thus find them an important aspect of the game, and they don't seem ugly to me. Why would they be?

I don't think it can be said that the developers had pixelated graphics in mind any more than they had marked light levels in mind... or they did (both), in the sense that those are technology aspects they made use of to produce and complete their games. I'm sure they would have used realistic 3D-looking monsters and more modern lighting like today's games provide, had technical possibilities allowed it. But yes, 3D video card effects can be seen as somewhat hacky on top of a 2.5D game... personally I think that issue goes farther than just the blurring.

Share this post


Link to post
myk said:

The problem with removing those lines is that light diminishing is much less noticeable, giving a bare feel, and in the end developers have to fiddle with it, either allowing something where the light diminishes at something like the original rate, or at a different rate that gives a visual impression that is closer to Doom's method. The lines also enhance the impression of movement, when they move with you. I thus find them an important aspect of the game, and they don't seem ugly to me. Why would they be?


The light diminishing with the associated color deteriotation was the main issue that drove me away from Doom 10 years ago - until I found the first decently working GL port.

To me this was and still is the biggest weakness of all software renderers.

Share this post


Link to post

I like the light diminishing with the associated color deterioration. I even reproduced this feature in beta of glboom+ with pixel shaders

Share this post


Link to post
entryway said:

I like the light diminishing with the associated color deterioration. I even reproduced this feature in beta of glboom+ with pixel shaders

Awesome. Is there anywhere I can find a Windows build of this? I'd like to see it in action.

Share this post


Link to post

Personally I dislike the noticeable bands of light level changes in the DOOM software renderer however I DO like the colour deterioration, it makes me think of modern saturation lighting techniques.

I'm interested to hear you've got that replicated with shaders entryway. Most likely I take a look at your implementation and use it for reference when we begin the upcoming Doomsday renderer overhaul.

Share this post


Link to post
esselfortium said:

Awesome. Is there anywhere I can find a Windows build of this? I'd like to see it in action.

Links should be in the prboom-plus thread IIRC. Currently it is not tested on various hardware (ATI and old geforces), but at least it works correctly on my gforce8800gts

http://prboom-plus.sourceforge.net/test4.zip

http://prboom-plus.sourceforge.net/doom01.png

Options/General/Allow Shaders: YES

Share this post


Link to post
entryway said:

That seriously kicks arse. I'm going to have to look into doing something similar in Doomsday so we can offer a truly "classic" rendering mode.

EDIT: Most likely I'll have two versions of the shader: 1)As in the above screenshot B)As above but with interpolation to smooth out the bands.

Share this post


Link to post

Indeed. I tried it out and it's seriously amazing. I love it.

Now if only something could be done to allow sprites to be drawn into the floor/ceiling rather than offsetting them or cutting them off...

Share this post


Link to post

I hate how OpenGL rendering is fucked by few of doom2.exe mapping effects (this sentence can works also in reversed).
It's why I still play in software rendering with Prboom+, I only use OpenGL with GZDoom (of course) because I use only specific wads for it.

Share this post


Link to post

ha thats great. i alway liked the software lighting, i even edited the lights file that GZDoom has to mark the player as a light source and turned the brightness down to replicate it in sharp clean hi-res GL.

Back in the day i always just thought the marine had a very small and crappy light on his helmet... and i liked it! i liked finding my way in the dark, i could see just enough to not run into walls or be too surprised by an enemy but enjoyably surprised none the less.

I always run PrBoom-Plus in software at low res anyway but maybe GZDoom could borrow this or my solution or both!

Share this post


Link to post
esselfortium said:

Now if only something could be done to allow sprites to be drawn into the floor/ceiling rather than offsetting them or cutting them off...

I think that could be rectified using a scene compositing shader and a more elaborate multipass rendering method.

Share this post


Link to post
DaniJ said:

That seriously kicks arse

but only nearest and bilinear are possible there. there is no way for aniso or trilinear

Share this post


Link to post
Graf Zahl said:

Why is that?

Real texture contains only indexes of colors and I get the real color of each pixel in realtime in shader from colormap texture and filtering must be done directly in shader. How can I make smoothing between MIP-levels in shader in this case?

// Fragment shader for hi-quality bilinear filternig
void DoFiltering()
{
  vec2 pixel_c  = vec2(rgbaBias) + 
    vec2(rgbaScale) * texture2D(tex, texCoord).rg;
  vec2 pixel_r  = vec2(rgbaBias) + 
    vec2(rgbaScale) * texture2D(tex, texCoord.xy + vec2(texelSizes.x, 0)).rg;
  vec2 pixel_b  = vec2(rgbaBias) + 
    vec2(rgbaScale) * texture2D(tex, texCoord.xy + vec2(0, texelSizes.y)).rg;
  vec2 pixel_rb = vec2(rgbaBias) + 
    vec2(rgbaScale) * texture2D(tex, texCoord.xy + texelSizes).rg;

  vec4 texel_c  = vec4(texture2D(texColormap, vec2(pixel_c.r,  cm)).rgb, pixel_c.g);
  vec4 texel_r  = vec4(texture2D(texColormap, vec2(pixel_r.r,  cm)).rgb, pixel_r.g);
  vec4 texel_b  = vec4(texture2D(texColormap, vec2(pixel_b.r,  cm)).rgb, pixel_b.g);
  vec4 texel_rb = vec4(texture2D(texColormap, vec2(pixel_rb.r, cm)).rgb, pixel_rb.g);

  vec2 lerpAmounts = fract(texCoord * texSizes);
  final = mix(
    mix(texel_c, texel_r,  lerpAmounts.x),
    mix(texel_b, texel_rb, lerpAmounts.x),
    lerpAmounts.y);
}


void main()
{
  texCoord = gl_TexCoord[0].st - halfTexelSizes;
  cm = clamp(Param2 - gl_FragCoord.x * Param1, cmMinScaled, cmMaxScaled);
  DoFiltering();
  gl_FragColor = final * gl_Color;
}

Share this post


Link to post

How about convert textures to HSV on load. Upload two versions of a texture, one plain luminance and the other hue+saturation. Use the luminance texture to render with as normal but lookup the hue+saturation texture in the shader to get the base color. You could then multiply the color over the top of the luminance texel whilst still allowing for mipmapping to work on the luminance levels. As we perceive less variation in hue compared to luminance it might look OK. Note there will probably need to be an additional render pass in there somewhere.

EDIT: On second thoughts, I don't think that would work the way I suggested but there must be a solution in that ballpark.

Share this post


Link to post
HackNeyed said:

but maybe GZDoom could borrow this or my solution or both!



Unlikely. It's sure an interesting concept but it depends on some restrictions that no longer exist in GZDoom (e.g. one palette for all textures) so all the truecolor capabilities would be nullified - and forcing mappers to deal with it by restricting themselves because you can be certain that the people using this feature will complain the loudest when maps look like shit (as in worse than they already do with the exisiting limitations.)

If I could get a shader working that could do Doom-like light diminishing without the banding and without restricting color use - yes I'd do it but if you are so desperate to use software lighting - use the software renderer!

Share this post


Link to post

Perhaps I'm missing something but why would this restrict rendering to one master palette? You could just as easily use multiple colormaps for lookup.

Share this post


Link to post
Graf Zahl said:

If I could get a shader working that could do Doom-like light diminishing without the banding and without restricting color use - yes I'd do it but if you are so desperate to use software lighting - use the software renderer!


This Doom-like lighting that entryway is working on would be perfect for glBoom's old-school update feel. Now while I'm fairly happy with my simple little text hack it would be awesome to have GZDoom implement a cleaner more uniformed and 'Doom-like' GL lighting system.

I do use the software renderer often for the Doom-like surreal\glow stick lighting and enemies that walk on the floor, not in it or float over it. If both those limitations could be overcome I would switch right to glBoom and GZDoom gl for fast sharp clean unfiltered high res goodness.

Yeah, I'm already dreaming...

Share this post


Link to post

I'm a big fan of the software renderer's look, but I also often use hardware rendering - if the map author intends that. My computer can't really handle hardware rendering anyway - it complains as soon as ~20 dynamic lights hit the screen.

Share this post


Link to post

It might be possible to get a very crude emulation of DOOM's color degradation simply by modifying the mipmap textures, i.e. after each shrink step (and before uploading to the GL) do a color degradation step.

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
×