Thomas Debesse (c00084bc) at 21 Oct 14:06

Rename "Find brush" to "Find Entity/Brush" in the menu and in the d...

This tool also allows you to search for entities.

@SpiKe thanks for the patch! Sorry for having missed the notification.

Thomas Debesse (c00084bc) at 21 Oct 14:04

Rename "Find brush" to "Find Entity/Brush" in the menu and in the d...

... and 10 more commits

Thomas Debesse (806c8fde) at 21 Oct 14:03

readme: more generic updates

... and 8 more commits

Solve host system and target system detection once for all.

Fix:

• So many warnings, failed to fully compile, and missing GTK GL Extension #207

What was expected to be an easy task (we already build GtkGLExt as a builtin for macOS) turned into a nightmare and a 12+ hours work. 💀️

Actually this work being done means I'm able to produce Windows NetRadiant builds anew… I discovered the old Windows VM I was keeping safe for building NetRadiant (without any MSYS2 regressions) could not build build GtkGLExt. And I could not install the packages required by GtkGLExt without updating MSYS2 and then bringing other MSYS2 bugs I had to fix.

Here is me running a release-like build of NetRadiant on Windows 11, rebuilt yesterday with this branch:

♦

My workflow relies on network shares (every build machines share the same folders, with unified commands). But executing within MSYS2 a program stored on a network share on Windows 11 makes it impossible to delete that executable until the file server is restarted AND the network share is disconnected and reconnected. But then the configure-based build (used by GtkGLExt) runs all its detection tests by crafting a temporary conftest.exe binary for every test in the source directory, overwriting that conftest.exe is overwritten after each test. That temporary program path cannot be redirected to some random temporary directory, so the first test passing makes all remaining tests failing, requiring the equivalent of a reboot of both the file server and the build machine client on every configure step (one can just restart the services and reopen sessions but you get the idea) while the whole configure run has to be restarted from scratch after every test, making it impossible to finish…

So that netradiant work has been crazy as I not only had to create a special GtkGLExt branch to get it build for windows again, implemented workarounds for converting windows paths to MSYS paths in cmake for configure subprojects, but also implement out-of-source build in GtkGLExt configure and implement subproject build in temp directory in CMake to workaround the MSYS2 bug… what a mess.

If you build on network shares, the easy-builder command should instead be:

EP_BUILD_DIR=/tmp/netradiant ./easy-builder

I updated the MSYS2 package installation instructions for Windows on the README. This now recommends the UCRT64 flavour (to be built from the MSYS2 UCRT64 shell) and requires more packages to be installed (to build the GtkGLExt builtin).

Like macOS, the GtkGLExt build for Windows now relies on a special windows branch hosted there:

• gitlab.gnome.org/illwieckz/gtkglext/-/tree/windows

Having a branch for each platform with their specific fixes likely breaking other platforms is the less costly solution. Given I'm the last people on Earth to actually maintain GtkGLExt, I will likely not spend any time to make a branch working everywhere.

This windows GtkGLExt branch may be force-pushed until this NetRadiant branch is merged.

I will likely have to fix the macOS build as well to fit the changes I did in the NetRadiant repository (I modified the build workflow…).

I added some commits to make heretic2, quake2 and quake3 tools build again. They're all the exact same fix reported to the different trees. I haven't tested that fix yet, one can verify if it works by building a map on Windows with q3map2 built from this branch.

This now uses the Yokai CMake framework. This is a framework I wrote for the Dæmon engine with future usage in NetRadiant in mind. This is meant to solve pitfals of CMake in detecting compilers, host and target systems, etc.

Work in progress documentation of Yokai can be found there: wiki.unvanquished.net/wiki/Tools/Yokai

Here are the detailed commit messages:

cmake: integrate the Yokai framework

Solve host system and target system detection once for all.

The upstream is maintained there:

• github.com/DaemonEngine/Daemon/tree/master/cmake/Yokai

cmake: rework the GtkGLExt builtins build

• Make possible to build GtkGLExt for Windows.
• Make possible to configure and build GtkGLExt outside of source to workaround the MSYS2 bug making impossible to delete an executable on a network share after execution (all build tests are done by replacing the same conftest.exe binary with a new one, in the source folder…).
• Add a EP_BUILD_DIR option to give an arbitrary build directory to let the user using network drives to build external projects (here: GtkGLExt) on a non-network directory to workaround that same MSYS2 bug.
• Translate or reconstruct MSYS2 paths to avoid CMake passing paths like C:\msys64\usr* to configure what would then be wrongly translated to /msys64/usr/* instead of /usr/* and fail.
• Use autoreconf instead of autogen.sh.
• Rework the compiler flags enablement.
• Add some compiler flags for compatibility purpose.
• Use a specially crafted Windows branch of GtkGLExt, like macOS.

cmake: rework the GTK selection and builtins enablement

• Only enable Radiant builtins when Radiant is built.
• Only set GTK2 when Radiant is built.
• Enable GtkGLExt builtin only on GTK2.
• Enable GtkGLExt builtin for Windows, MSYS2 dropped it.

easy-builder: rework and make it more robust for GtkGLExt building on MSYS2

• Unset MSYS2_ARG_CONV_EXCL (if set) in case the user changed the default, the paths used by CMake and Configure commands used for building GtkGLExt are very messy, but we better deal with a consistent mess.
• Rework the jobs enablement to set it for all CMake calls once for all.
• Rework the CMake invocations to not call Make directly.
• Now make CMake use -S and -B for source and build directories.

heretic2: fix threads on Windows quake2: fix threads on Windows quake3: fix threads on Windows

Fix:

tools/quake3/common/threads.c:207:33: error: passing argument 6 of 'CreateThread' from incompatible pointer type [-Winc
ompatible-pointer-types]
  207 |                                 &threadid[i] );
      |                                 ^~~~~~~~~~~~
      |                                 |
      |                                 int *

This should be good enough, and if improvements may be found, that doesn't introduce regressions since it's currently broken.

Thomas Debesse (806c8fde) at 21 Oct 14:02

readme: more generic updates

... and 9 more commits

Thomas Debesse (a4b21156) at 21 Oct 14:01

radiant: display which GTK is used in About dialog

Display which GTK is used in About dialog.

Thomas Debesse (a4b21156) at 21 Oct 14:01

radiant: display which GTK is used in About dialog

Hi,

Since I'm not knowledgeable about NetRadiant code and C in general, I asked Claude to help trace this — sorry if LLM are not your cup of tea (which I'd understand).

Anyway, Claude seems to confirm what I've observed:

RadSubdivideDiffuseLight() used to take a qboolean original parameter: qtrue only on the initial (un-subdivided) call from RadLightForTriangles()/RadLightForPatch(), and qfalse on every recursive subdivision call. The point backsplash was gated behind if ( original && si->backsplashFraction > 0 ).

Since the function subdivides before reaching that check, any surface exceeding diffuseSubdivide (256 units by default, or q3map_lightSubdivide) in some axis recursed immediately with original == qfalse, so none of its resulting fragments ever got a backsplash — only small, already-fitting surfaces did.

Commit ed4c8c20 (2017-08-02, the one introducing Jelvan's area-light backsplash) dropped this original parameter entirely from the function signature, so backsplash is now created on every subdivided fragment instead of only on the original whole surface. !210 (merged) restored the point-light algorithm but not this original gating, since that logic had been removed from the function itself, not just swapped out.

Thanks for the report!

It seems that point backsplash was once applied only to small light-emitting surfaces, but is now applied to all surfaces, even large ones.

Was there code to disable backsplash from some surface?

It seems that point backsplash was once applied only to small light-emitting surfaces, but is now applied to all surfaces, even large ones.

For example, we didn't get these artefacts in old builds of Afterslime:
♦

Point light backsplash had been removed in ed4c8c20 in favour of area light backsplash, then later reintroduced in !210 (merged)

But perhaps it was the old behaviour (disabling the backsplash for large surfaces) that was considered a bug?

More examples with the following Xonotic map: test2.map

• With NetRadiant 20220628 and backsplash: ♦
• With current NetRadiant and the default backsplash values: ♦
• With current NetRadiant and -backsplash 0 0 ♦