How we fixed map overbright

[illwieckz]

In our Renderer FAQ we have this statement:

• Q: Did the overbright patches change the way legacy maps are rendered?
• A: No, they restored the way legacy maps were rendered. Previously we had a bug, so if you see a change, it's because a bug was misrendering something before.

It may look like a very bold statement and some people may actually believe it's not true, after all there are some unlucky players around there that may have never played without overbright bugs since 30 years (that's very sad, truly).

The FAQ also states this:

• Q: Is the original overbright configuration used when rendering legacy maps?
• A: Yes, when rendering legacy maps (or maps built the old way), the default overbright settings are the ones from the reference id Tech 3 experience which was “players playing full-screen on Windows”, we also have historical screenshots showing unambiguously that such overbright configuration was the expected behaviour in Tremulous time as well.

So, here comes the proof:

Tremulous 1.1.0, Windows (2006 build)	Tremulous 1.2.0 GPP, Linux (2009 build)
GrangerHub Tremulous 1.3.0a-0.12 (ioq3 renderer), Linux (2017 build)	Unvanquished 0.54.1, Linux (2023 build)
Unvanquished 0.56.2, Linux (2026 build)	Unvanquished 0.56.2 (with tone mapping), Linux (2026 build)

As we can see, the 0.56.2 render without tone mapping is the closest render to Tremulous 1.1.0 on Windows (the reference renderer) and to the ioq3 renderer used by GrangerHub Tremulous 1.3.0. So yes overbright has indeed been fixed.

It happened that Both Tremulous 1.1.0 on Linux, Tremulous 1.2.0 on Linux and Unvanquished before 0.55 shared the same bug that that was initially a Quake 3 linux bug, that bug destroyed 75% of the precomputed light data at render time.

And I will emphasis on this statement: if you do believe the Tremulous 1.2.0 and Unvanquished 0.54.1 render are the correct ones and the ones you expect, that's because 30 years of bugs have built up wrong expectations in you, you may have never seen the light at all (no pun intended) because the renderer was destroying 75% of it.

That bug was initially a bug in the Quake 3 engine for Linux and Linux players got a subpar implementation at the time, and this bug extended to over platforms over time when the Windows-specific overbright implementation had been dropped in some of Dæmon's parent (XreaL or Tremulous GPP, I don't know).

Both ioq3 and the Dæmon engine have a fixed renderer with correct overbright. It's probably true in ioq3 for more then a decade. Us only fixing it around 2024 meants we were very late at fixing that bug.

GrangerHub Tremulous started doing alpha releases based on ioq3 around 2017, 9 years ago, and them did not revert the overbright fix from upstream ioq3. That overbright we can see in both Windows Tremulous from 2006, GrangerHub Tremulous from 2017, and Unvanquished/Dæmon since around 0.55 in 2024 is the correct and expected render.

Note about the last screenshot: the tonemapping feature is purposed to rework the lighting by design, and is expected to make the image brighter with the current settings. The tonemapping feature has been first implemented to workaround Tremulous maps being too dark. A similar light intensity difference would also happen when using adaptive lighting, which requires tone mapping by the way. This is not a bug and one can disable tone mapping if he dislikes it. That is not a bug, it's a feature that was requested and praised by the players.

[illwieckz]

So it would be very nice if people stop blaming developers who spent their precious time fixing bugs everyone in the id Tech 3 ecosystem is fixing since decades, to bring players the render John Carmack himself intended, and that the original Tremulous delivered, and that Tremulous revivals brought back a decade ago.

[cu-kai]

[...] Tremulous revivals brought back a decade ago.

I don't know what "revivals" you're talking about, the game had a steady-ish playerbase during that decade, many of the other players had already left. Nothing was "revived" during that time.

[illwieckz]

I meant as a development project, GrangerHub picked development and revived it in some ways (or gathered developers if you prefer). There had been other projects like TremFusion, things like that. I'm not talking about player base here but about developer base.

Both Quake 3 and Tremulous community development efforts released builds fixing this overbright bug, Unvanquished is no special on that part and did the same.

[killing time]

Lack of overbright on Linux wasn't a bug (programming error) to start with. There was no API to apply it "for free" with a lookup table like on Windows, so I imagine it was deemed to be too expensive to implement. Once GL2 renderers appeared though, it should have been easy to fix on all platforms.

With 0 bits of overbright (and a 2-bit shift as there has always been), you throw away 2 out of 8 bits of precision, or 25%. What a waste! With the correct 1 bit of overbright, we throw away 1 bit of precision. Only 12.5% loss, yay!

Only the sRGB maps really use 100% of their bits.

[cu-kai]

I meant as a development project, GrangerHub picked development and revived it in some ways (or gathered developers if you prefer). There had been other projects like TremFusion, things like that. I'm not talking about player base here but about developer base.

You are still wrong about that too, please do not make assertions about Tremulous history, this is also not relevant to the thread.

[illwieckz]

What is relevant is that both Quake 3 and historical Tremulous-related projects fixed overbright, Unvanquished would be an exception to not do, and not doing it would go against the compatibility goal.

The details of the history and which word you or me would use to describe and qualify the history is not relevant. Your comment “I don't know what "revivals" you're talking about” was out of topic to begin with. We may disagree on the wording but the topic is feature compatibility and restoration.