OrbWeaver

As our other mappers have stated, optimising brushwork is nowhere near as important in this engine as it was in previous ID games, however optimising lights (especially those that cast shadows) has become a lot more important since lights are rendered at runtime rather than precalculated and baked into the map. Having 100 overlapping shadow-casting lights illuminating a simple brush is going to have a much greater impact on performance than a complex brush illuminated by a single light.

I think you're looking at the text in menus and the console window, which should indeed scale. Grayman is talking about the text on OpenGL windows, e.g. for the grid coordinates and the size of selected objects. In your screenshot this text can be seen at the bottom of the 3D view showing render statistics, and this does appear to be the same size in both images.

As far as I know it's just a fixed pixel size (not a point size) so I doubt it will scale with Windows font scaling, although it might scale if there is a global DPI scale which also affects the wxGLCanvas widget.

Currently, no, it's hard-coded. And worse than hard-coded, there's actually only one size available for the whole application to draw with, so it's not even possible for different parts of the interface to use differently-sized text. I too find the text too small (and I'm only 38), and I did very slightly increase it in one of my local commits while working on renderer-related tasks, but it would be nice to fix this properly so that users could configure whatever size they found most readable.

It would be permitted as long as the libraries we installed did not conflict with system libraries; i.e. we would need to install them somewhere like /usr/lib/darkradiant/libwx_whatever.so rather than in /usr/lib. But it would definitely be complicated, because not only would we have to build the wxWidgets library (which is pretty straightforward), but build DarkRadiant to link against it in such a way that the correct library would be found at runtime, even though the library location at runtime would be completely different from the library location at build time (which means that a def

One option would be to move to using our own build of wxWidgets rather than relying on the system version (i.e. basically what I assume we are doing on Windows already, but on Linux too). Since the wxWidgets project is using Git, we wouldn't even need to store a tarball, we could just have a submodule like 3rdparty/wxwidgets which can be checked out automatically. There would of course be build script work needed to get our configure/automake system to first build the wxWidgets library and then use it instead of the system-wide version, and I don't know if there would be downsides like be

You'd think there would be something in the vast list of public methods on wxWindow, but I could not find anything either. Things which definitely did not work: _glWidget->PostSizeEvent() _glWidget->Fit() GetSizer()->Layout() _glWidget->Hide() followed by _glWidget->Show() _glWidget->Disable() followed by _glWidget->Enable()

Some more weirdness: if I switch to another window and back to DarkRadiant, the preview widget suddenly starts to update on selecting textures, exactly as it should. But it never works the first time I start DarkRadiant. It's like the widget starts up in a sort of "standby" state, and doesn't start to get repainted until the window is switched to from another application.

Reproduces for me on Ubuntu 20.04. I can only assume it's a bug in WxWidgets. The docs are clear: if you call Refresh() on a widget it should queue a paint event, and if you call Update() (possible after calling Refresh() to first invalidate the widget) it should do a repaint immediately. But it refuses to do so. Instead it seems to be queuing the paint events internally somehow, and only releasing them when it feels like it, e.g. in response to resizing or switching to another application. Or maybe a problem with the underlying GTK/GDK library itself. It seems others have reported s

I will see if the issue reproduces on my machine (currently Ubuntu 20.04, I only use LTS releases on my main machine). It looks like the sort of problem that can probably be solved by adding some extra "refresh window" call in a suitable location, even if it isn't entirely obvious why the existing code doesn't work. I seem to remember encountering a similar issue when hiding/showing the 3D camera view toolbar (you'd have to resize the widget before it would actually disappear).

We do have an option called something like r_showSounds, which shows playing sounds and their locations and I think (but could be misremembering) this also includes the current ambient sound. But perhaps it only shows ambient sounds that are associated with specific speaker locations rather than background music.

Thanks for the pointer, I'll see if the associated commits fix the problem on my machine.

I'm happy to push the 2.9.1 version into my PPA. As Greebo says, we don't have direct control over the version that goes into Debian proper, that's up to their own maintainer(s).

infirmity, decrepitude, senility and dotage seem to be the most common suggested translations from "Altersschwäche", although interestingly none of them seem to be an exact match. infirmity means sickness or weakness, but doesn't include the meaning of "old". Old people are often infirm (and often described as "old and infirm") but you can also be infirm without being old. decrepitude is probably the closest match, with a meaning of "decay due to old age", although I've most often heard it applied to buildings and objects rather than people. I think calling an old person "decrepit" w

Having just upgraded to Ubuntu 20.04, I can now reproduce this problem. As of Git 6a093c45fad6bb69ed4ccd8e76df121313917cfc, I am now explicitly requesting python3-config instead of the unversioned and deprecated python-config, which fixes the compilation error but does not fix the loading of the script module due to the missing _Py_ZeroStruct symbol.