git.rm.cloudns.org Git - xonotic/darkplaces.git/log

]> git.rm.cloudns.org Git - xonotic/darkplaces.git/log

projects / xonotic / darkplaces.git / log

drjaska [Tue, 3 Dec 2024 06:36:19 +0000 (08:36 +0200)]

Change the shade of Quake blue to make it readable (#217)

Commits:

- 465d2925 Revert "Change directory text colour in console from blue to
light cyan (https://github.com/DarkPlacesEngine/DarkPlaces/pull/197)"
This reverts commit
https://github.com/DarkPlacesEngine/DarkPlaces/commit/0c17657b4a2562f6c1d9e0a0707faff825dd8ce5.

This was a band-aid fix to a single issue and does not address the root
cause or any of the other issues where the Quake blue colour is not
readable.

- a48ccf0

This is my attempt at making the Quake blue more readable.

---

The changes can be tested for example via `echo
^1aaa^2aaa^3aaa^4aaa^5aaa^6aaa^7aaa^8aaa^9aaa` or `playdemo` tab
completion.

---

`gl_draw.c:862` has the colour definition of blue which is too dark to
be readable in several cases. It is currently set to `#0000FF` in hex,
pure blue. Changing this should be preferred over the change in
https://github.com/DarkPlacesEngine/DarkPlaces/pull/197 as directories
in the console are not the only issue and this avoids making all
directories have the colour of symlinks, breaking the decades long
default UNIX terminal colour theme.

The colour code which (if sys_colortranslation > 0) is output to the
stdout which is often visible on a terminal running the engine gets the
ANSI colour code from `console.c:1367` BUT the user's terminal decides
what colour the colour code is rendered as and thus this doesn't require
any change. If sys_colortranslation == 3 and the terminal supports 24bit
colours then terminal colours are not used but the RGBA colours.

It is worth noting that `cmd.c:669` already includes a hack:
```c
// Work around low brightness and poor legibility of Quake font
"r_textbrightness 0.25\n"
"r_textcontrast 1.25\n"
```
which may affect how your colours are drawn as these values are not the
default values. Mods may also set these. Xonotic uses a different font
and
```quake
r_textbrightness 0.2
r_textcontrast 0.8
```
which I guess is neutral with the math formula in `console.c`:
```c
bound(0, rgb[i] * r_textcontrast.value + r_textbrightness.value * 255, 255);
```
Note that the `r_textcontrast 1.25` hack which I think applies to
vanilla Quake 1 progs looks like it shouldn't actually accomplish
anything due to the 255 bounding except raise the brightness of the
"half brightness" colour. But for some reason changing `r_textcontrast`
to 2 causes a jump in brightness but 2 to 3 or any above ones do not. Is
there something halving the text colour in Quake 1 console? Though after
my change it does affect the shade of blue as it has values which are
not maxed at 1.0 or values like 0 which are not affected by the
multiplication. I would recommend considering removing it.

---

original and a48ccf0 comparisons:

| original | a48ccf0 |
| ------- | ----------- |
| Xonotic | Xonotic |
| DP no progs console r_textbrightness 0 r_textcontrast 1 | DP no progs
console r_textbrightness 0 r_textcontrast 1 |
| DP no progs console r_textbrightness 0.25 r_textcontrast 1.25 | DP no
progs console r_textbrightness 0.25 r_textcontrast 1.25 |

![image](https://github.com/user-attachments/assets/d7e4c809-db82-49f4-b30c-42939d199b7d)

I would not recommend changing the colours globally as there are mods
and users who have already made their colours good and visible. Just
blanket adding 0.25 brightness to all colours causes Xonotic's colours
to look very washed out. Game specific fixes should be encouraged like
the Quake 1 progs and Xonotic ones as they all use different fonts and
lighting (text and screen).

---

I did also look at a patch which bakes in r_textbrightness 0.25 into the
base colours but chose not to include it due to the reasons in previous
chapter.