Automap rendering in GZDoom

[eiUACei]

For some reason there is absolutely no antialiasing in OpenGL automap in GZDoom. Both lines are polygon edges are aliased. But there is line antialiasing in software renderer's automap. And even more strange, there is antialiasing in OpenGL renderer's normal game view! How do I turn on line antialiasing in OpenGL renderer's automap?

Also, textures automap looks worse in OpenGL because textures are darker. Here's an example from Combat Shock that basically sums the differencies between renderers. Software is on the left.



Not only blood, but look at wood and metal. OpenGL screenshot without mipmapping for fair comprasion.

It seems like both renderers get the texture brightness like if you were viewing a texture point-blank and since nearby textures light up way more in software renderer than in OpenGL renderer, the automap looks better. How do I make textures in OpenGL automap brighter without altering normal game view?

[Graf Zahl]

None of this can be changed. The problem I had with line antialiasing in GL is that it looked totally smeared so I disabled it.

The lighting differences come from the way this is calculated. The software renderer uses its internal tables to calculate brightness. The GL renderer does not uses them, in fact it cannot use them, so it uses its own lighting calculations for the 3D view which are slightly different.

[entryway]

Graf Zahl said:

None of this can be changed. The problem I had with line antialiasing in GL is that it looked totally smeared so I disabled it

Looks good for me in most cases

[eiUACei]

Graf Zahl said:

The problem I had with line antialiasing in GL is that it looked totally smeared so I disabled it.

But SLADE uses hardware antialiasing and looks good. Doom Builder 2 uses hardware antialiasing and looks good. Heck, even my own stupid OpenGL map viewer uses hardware antialiasing and looks good if I make lines a bit bolder. How is GZDoom automap different?
BTW I remember that an old Skulltag version had automap antialiasing in OpenGL renderer while current GZDoom version at that time didn't.

Graf Zahl said:

The lighting differences come from the way this is calculated. The software renderer uses its internal tables to calculate brightness. The GL renderer does not uses them, in fact it cannot use them, so it uses its own lighting calculations for the 3D view which are slightly different.

And why does software automap use tables that are brighter than the sectors really are? Is it intentional to make textured automap look better? And isn't it possible to brighten up textures on OpenGL automap?

[Graf Zahl]

eiUACei said:

And why does software automap use tables that are brighter than the sectors really are? Is it intentional to make textured automap look better? And isn't it possible to brighten up textures on OpenGL automap?

I have no idea what precisely the software renderer does. The GL renderer uses the light levels 1:1 and just because you don't happen to like it won't mean that it's going to change.

[Gez]

Is it possible that the smeared look was a local issue (poor hardware/driver at the time)? If it's just changing a parameter or two in a couple of function calls, it'd be worth it to make it an option.

[Graf Zahl]

Possible. That was years ago and I never revisited the code since then because the missing antialiasing doesn't really bother me.

It's only adding one line of code to re-enable it.

[tempun]

entryway said:

Looks good for me in most cases

I'd like the lines to be thinner, is there a config setting for it?

[Enjay]

entryway said:

Looks good for me in most cases

The MAP01 shot looks fine (but no better IMO). The Vracky one looks quite "smeary" to me and not as good as the non anti-aliased version IMO.