Open GL mode or Software mode?

[Coraline]

I've always liked OpenGL more. Granted, Software goes well with faithful Doom-style mods but for newer (more abstract) stuff, it simply shines in GL.

Also, you really can do more with maps with OpenGL (true 3d floors, dynamic lights, etc), which allows you to make some pretty awesome stuff in it.

[Spinesplitter]

DaniJ said:

Most (all?) OpenGL source ports provide options to change how sprites are drawn. You can have them aligned to the view plane, just like the software renderer if you wish.

im talking dimension wise

[Spinesplitter]

Oh never mind i see what you mean i misunderstood you sorry.

[Graf Zahl]

Wagi said:

GZDoom barely does this. Graf said it looked unnatural.

It does half the strength of the software renderer. Fake Contrast, after all, is merely a hack to add more definition and too much of it can be disruptive. With true color even more.

Phobus said:

I quite like the additional vibrancy of software rendering. Particularly when compared to how two dimensional the textures, flats and sprites look in OpenGL, due to it being a full 3D environment.

That doesn't make any sense. It merely sounds like you are using a lower gamma on software than on hardware rendering. Too high gamma can indeed make things look flat and dull.

[Reisal]

OpenGL preferably, because I don't like the color fade off with software.

[Gez]

Graf Zahl said:

It does half the strength of the software renderer. Fake Contrast, after all, is merely a hack to add more definition and too much of it can be disruptive. With true color even more.

Where does this halving takes place? The only things I could find was the default value of gl_weaponlight set to 8 instead of 16 like in software (but since it's a console variable people can change it if so they want); and in gl_CalcLightLevel the halving of relative light if it's negative and the light is below gl_light_ambient (which by default is 20, so it's rarely halved).

[Graf Zahl]

Gez said:

Where does this halving takes place? The only things I could find was the default value of gl_weaponlight set to 8 instead of 16 like in software (but since it's a console variable people can change it if so they want);

That's what I meant. I didn't remember that it actually was a console variable. Even better. ;)

Gez said:

and in gl_CalcLightLevel the halving of relative light if it's negative and the light is below gl_light_ambient (which by default is 20, so it's rarely halved).

That's different and was needed because it would have caused extremely strong light flashes from weapon firing.

[Gez]

Graf Zahl said:

That's what I meant. I didn't remember that it actually was a console variable. Even better. ;)


That's different and was needed because it would have caused extremely strong light flashes from weapon firing.

So, with that single exception, fake contrast is not halved? Only weapon extra light is?

[Graf Zahl]

I haven't looked at the code for ages but it seems so.

[eiUACei]

Wagi said:

1) Curving the sky into a sphere, even if the sky is composed of mountains.

That's very hard to notice. I can't remember a single wad where mountains are that tall.
And it is nothing comared to what software renderer does to skies:
1) It streches skies on left and right sides of screen. OpenGL does not re-strech skies as you turn.
2) When freelook is needed software renderer must either tile the sky or stretch it vertically.
But in OpenGL the sky is almost not stretched.

Wagi said:

I'm not bothered by software's freelook because
1) The "stretching effect" is barely noticable at Heretic/Hexen's original freelook limits.
2) There is rarely a reason to look up/down that far in Doom engine games, and even then vertical hitscans are buggy, so what's the point?

1) IMHO no. Unlike OpenGL sky distortion. Max freelook in software makes me want to immediately switch to GL. Better seen on very tall architecture like MAP15.
2) The point is to be less annoyed because of limits. Trying to look down deep pit or on monsters in some tall building makes player change his position even though nothing obstructs the view. The more cramped and tall the level is, the more noticeable the freelook limit and distortion get.

Graf Zahl said:

Despite many claims to the contrary, there is no 'right' way to play Doom. What does constitute proper lighting? Even the software renderer's was subject to the gamma correction feature - and that had much more severe effects than OpenGL - so anyone stating that there's precisely one correct way for Doom to look is flat out wrong

Almost any graphical setting which affects color may be abused to break the look of map. This includes port settings, OS settings and display settings. What I mean by "right" rendering is how a map was intended to look but now I get it: sometimes the "wrong" way is more beautiful than what was intended. But sometimes not. I feel like software rendering is generally better for small, cramped maps and OpenGL is better for huge open ones.

[ducon]

Ah, and I can I play Doom, even if the nVidia driver crashed, with the software mode.

[_bruce_]

Software all the way.

A game like Blood would be an entirely different matter - a 3dified version seems fitting for this... let's hope BloodXL is out soon.

[phi108]

One thing that I would like to see in a GL engine is a different filtering method applied to the first mipmap level versus the second and all other further mips. Up close, I like the unfiltered raw look for sprites and textures. But with no filtering and nearest-neighbor mipmapping, far away views can have some aliasing during movement. I prefer bilinear/trilinear filtering for faw away scenes, so if a GL engine could somehow make that filtering switch at the first mipmap level, I wonder if it would look any good.

[Phobus]

Graf Zahl said:

It merely sounds like you are using a lower gamma on software than on hardware rendering. Too high gamma can indeed make things look flat and dull.

I don't think that's it - I've spent a lot of time fiddling with the lighting options and brightness in OpenGL when playing it to try and be satisfied with the look of it and I'm yet to have acheived a balance that I'm happy with.

[Lila Feuer]

I prefer software nowadays (Choco/Doom95/PrBoom+) but will use OpenGL/hardware accelerated ports (GZDoom/GLBoom/Doomsday) when called for it. I like the dynamic lighting in GL mode but prefer the lighting/shading method used in software.

[Graf Zahl]

phi108 said:

One thing that I would like to see in a GL engine is a different filtering method applied to the first mipmap level versus the second and all other further mips. Up close, I like the unfiltered raw look for sprites and textures. But with no filtering and nearest-neighbor mipmapping, far away views can have some aliasing during movement. I prefer bilinear/trilinear filtering for faw away scenes, so if a GL engine could somehow make that filtering switch at the first mipmap level, I wonder if it would look any good.

GZDoom has a mode which doesn't use bilinear filtering but does use mipmaps. That should give you what you want. It's 'none (linear mipmap)'

[Optimus]

I am playing in Zdoom software rendering unless a WAD requires GZDoom. Many reasons to dislike acceleration currently, first I don't like how the bilinear filtering of the sprites look (of course you can disable filtering), then for some reasons I get motion sicknessed by accelerated ports. I even prefer unfiltered texture walls, I don't know why. Maybe I got used to Zdoom too much.

[Avoozl]

The only thing I don't like about open gl is that it seems to make any sprites colour coded orange look like mustard yellow.

[Dragonsbrethren]

I used to be a software rendering fanboy, but now that I have a monitor that can do resolutions higher than 1280x1024 I really have to say I prefer hardware rendering for the speed advantage when I want to take advantage of those resolutions. I've even learned to love the filtering, though I still think those "hi-res" upscalers look hideous.

The only thing I wish more hardware rendering ports would do is implement better distance fading. GLBoom-plus has a fog-based option that looks like a perfect high color version of what vanilla does, outside of the lighting seeming to be a bit too bright overall. Pair GZDoom's lighting with GLBoom-plus's fog-based distance fading and I think it would be near-perfect looking.

The only other problem with hardware renderers is the sprite clipping. I've always wondered (as a complete idiot when it comes to doing any programming that is practical for today's world) if it would be possible to do a software pass for the sprites, which keeping the geometry itself hardware rendered. Maybe it would kill the speed as bad as a true software renderer, I don't know, it's just something I'm curious about.

[Graf Zahl]

Dragonsbrethren said:

The only other problem with hardware renderers is the sprite clipping. I've always wondered (as a complete idiot when it comes to doing any programming that is practical for today's world) if it would be possible to do a software pass for the sprites, which keeping the geometry itself hardware rendered. Maybe it would kill the speed as bad as a true software renderer, I don't know, it's just something I'm curious about.

Aside from killing the performance it wouldn't help, for various reasons:

1. The clipping info for such a pass does not exist. If it did it could also be done in hardware directly.
2. Geometry transformation is not identical unless looking straight ahead so even if it could be done it would not match.

[Marnetmar]

I don't use OpenGL unless I'm playing Brutaldoom or some other mod that requires it.

[Dragonsbrethren]

Graf Zahl said:

Aside from killing the performance it wouldn't help, for various reasons:

1. The clipping info for such a pass does not exist. If it did it could also be done in hardware directly.
2. Geometry transformation is not identical unless looking straight ahead so even if it could be done it would not match.

Thanks. That's pretty much what I figured; if it was as easy as I thought it might be, then at least one port probably would've done it by now.