Add the q3map_backsplashPoint and q3map_backsplashArea shader keywords.

• q3map_backsplashPoint: legacy point light backsplash.
• q3map_backsplashArea: area light backsplash.

Without them the default or what command line requested is used.

Thomas Debesse (0c813a34) at 10 Nov 16:13

q3map2: add the q3map_backsplashPoint/Area shader keywords

Thomas Debesse (9cf62fee) at 10 Nov 16:11

Thomas Debesse (0c813a34) at 10 Nov 15:38

q3map2: add the q3map_backsplashPoint/Area shader keywords

... and 1 more commit

Context: It is highly recommended to use a non-fast light stage (even if light bounces are fast) as it produces much better graphics, and current computers are fast enough to compute that, see for details: forums.unvanquished.net/viewtopic.php?t=2181

The q3map2 tool recognized the q3map_noFast option to force a given light shader to not be fast when the whole build was set as fast, but it lacked the q3map_fast option to force a given light shader to be fast when the whole build was set as non-fast.

Actually it doesn't really make sense for a new map to use a fast light falloff, but when rebuilding an existing map that was tested with a fast build, this may not give the expected results on some edge case. This situation is believed to be rare, but it can happen.

Here is an example of the hangar28 map for Unvanquished from 2017, the translucent force field dome uses a shader emitting some cyan light to pain the nearby surface as a special effect. It's a sci-fi effect and isn't meant to be physically correct:

♦

When using a non-fast light falloff, the whole place is painted in cyan:

♦

Using the q3map_fast option, we keep the special effect working as the mapper tested it:

♦

I only expect this keyword to be used on things that aren't really lights but are implemented as light shaders as a way to intentionally bleed some colors. This is meant for compatibility.

First screenshot is using a fast build. Second and third screenshots are using a non-fast build (they also use a more recent source directory, hence the difference due to normal maps). The third screenshot also uses q3map_fast on the force field shader to keep the legacy behavior of the emitted color.

Thomas Debesse (9cf62fee) at 10 Nov 15:38

q3map2: add the q3map_fast option to force the usage of a fast ligh...

Thomas Debesse (9cf62fee) at 10 Nov 15:37

q3map2: add the q3map_fast option to force the usage of a fast ligh...

... and 2 more commits

Thomas Debesse (4acad803) at 10 Nov 15:37

q3map2: add the q3map_backsplashPoint/Area shader keywords

I split the option as two keywords: q3map_backsplashPoint and q3map_backsplashArea.

It makes the name explicit and then easier to read without having to remember what value was for what, also other keywords usually don't use booleans so this wasn't consistent.

It's also consistent with the -backsplashpoint and -backsplasharea command line options.

Fixed

Thomas Debesse (6f218e98) at 10 Nov 15:26

q3map2: add the q3map_backsplashPoint/Area shader keywords

... and 5 more commits

In Debian, we like (maybe at little bit too much) manpages. Ideally we would have one for each cli tool, but we have to start somewhere.

This has been merged by hand, and I added a commit to use our existing install path mechanism to make it more portable.

Thanks.

Thomas Debesse (c6f47de1) at 10 Nov 15:15

cmake: make man page installation more portable and leverage our cm...

... and 1 more commit

Context: It is highly recommended to use a non-fast light stage (even if light bounces are fast) as it produces much better graphics, and current computers are fast enough to compute that, see for details: forums.unvanquished.net/viewtopic.php?t=2181

The q3map2 tool recognized the q3map_noFast option to force a given light shader to not be fast when the whole build was set as fast, but it lacked the q3map_fast option to force a given light shader to be fast when the whole build was set as non-fast.

Actually it doesn't really make sense for a new map to use a fast light falloff, but when rebuilding an existing map that was tested with a fast build, this may not give the expected results on some edge case. This situation is believed to be rare, but it can happen.

Here is an example of the hangar28 map for Unvanquished from 2017, the translucent force field dome uses a shader emitting some cyan light to pain the nearby surface as a special effect. It's a sci-fi effect and isn't meant to be physically correct:

♦

When using a non-fast light falloff, the whole place is painted in cyan:

♦

Using the q3map_fast option, we keep the special effect working as the mapper tested it:

♦

I only expect this keyword to be used on things that aren't really lights but are implemented as light shaders as a way to intentionally bleed some colors. This is meant for compatibility.

First screenshot is using a fast build. Second and third screenshots are using a non-fast build (they also use a more recent source directory, hence the difference due to normal maps). The third screenshot also uses q3map_fast on the force field shader to keep the legacy behavior of the emitted color.

Thomas Debesse (060e2a4b) at 31 Oct 18:03

q3map2: add the q3map_fast option to force the usage of a fast ligh...

It also supports:

• OpenArena
• Q3Rally
• Reaction
• Smokin' Guns
• Unvanquished
• WarFork

Can you sort the entries alphabetically?

Can you sort that alphabetically?

Not platforms but games.

Spike29 (04201ff5) at 28 Oct 09:42

Merge branch 'spelling' into 'master'

... and 1 more commit

fix "spelling-error-in-binary" reported when packaging netradiant for Debian; it shouldn't hurt

Thanks, it can't hurt indeed.

In Debian, we like (maybe at little bit too much) manpages. Ideally we would have one for each cli tool, but we have to start somewhere.