greebo

Yes, there are about 5 or 6 code parts making use of fonts, and I moved most of those sizes to the user.xml file. Only the orthoview settings are accessible through the preferences, the rest can only be modified through your user.xml file. Unfortunately the measurement tool still uses the hardcoded default font size 14. If you like to modify it, please open a request on the tracker, I'll see what I can do.

Thanks, it's merged! And a new pre-release build is available in the first post.

Just merged orbweavers's changes, can you please check again?

Compiling on openSUSE is working with ENABLE_RELOCATION=ON, but startup fails. I think this is because ENABLE_RELOCATION and lib64 doesn't work together: std::string ApplicationContextBase::getLibraryBasePath() const { #if defined(__APPLE__) return _appPath; #elif defined(POSIX) # if defined(ENABLE_RELOCATION) return _appPath + "../lib/darkradiant/"; # elif defined(PKGLIBDIR) return PKGLIBDIR; # else # error "Either PKGLIBDIR or ENABLE_RELOCATION must be defined" # endif #else // !defined(POSIX) return _appPath; #endif } With activated ENABLE_RELOCATION the module search paths are using hardcoded ../lib which is not working here. Should we pass the lib64 or lib folder name into here using a preprocessor define?

I think I'm rather leaning towards leaving it ON then, sounds like it's more flexible. I'll check out if it work with the newest fixes. edit: worked!

Thanks, I've pulled your changes into my repo. What about the libjpeg package being required instead of libjpeg62? I can update the wiki to adjust the necessary packages, but what's the difference anyway?

Hm, I just compiled in Ubuntu 20.10 and it's working. Do you have the zlib1g-dev package installed? What were the steps you used to compile DR?

I added two commits fixing the compilation in Mageia. I built DR with >> cmake . -DCMAKE_INSTALL_PREFIX=/home/greebo/dr >> make >> make install With that DR still fails to startup with a linker error: >> ./darkradiant: error while loading shared libraries: libwxutil.so: cannot open shared object file: No such file or directory LDD shows me this: ldd ~/dr/bin/darkradiant linux-vdso.so.1 (0x00007ffc233b1000) libwxutil.so => not found libxmlutil.so => not found libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fd80d80d000) libscenegraph.so => not found libmath.so => not found libwx_baseu-3.0.so.0 => /lib64/libwx_baseu-3.0.so.0 (0x00007fd80d596000) libwx_gtk3u_core-3.0.so.0 => /lib64/libwx_gtk3u_core-3.0.so.0 (0x00007fd80cf53000) libwx_gtk3u_stc-3.0.so.0 => /lib64/libwx_gtk3u_stc-3.0.so.0 (0x00007fd80cd46000) The files are present in the installation target, in the lib64 folder: ls -l ~/dr/lib64/darkradiant/ total 2156 -rwxr-xr-x 1 greebo greebo 56240 Dec 20 06:00 libmath.so* -rwxr-xr-x 1 greebo greebo 287352 Dec 20 06:00 libscenegraph.so* -rwxr-xr-x 1 greebo greebo 1794056 Dec 20 06:03 libwxutil.so* -rwxr-xr-x 1 greebo greebo 52072 Dec 20 06:00 libxmlutil.so* drwxr-xr-x 2 greebo greebo 4096 Dec 20 06:33 modules/ drwxr-xr-x 2 greebo greebo 4096 Dec 20 06:33 plugins/ I seem to have ENABLE_RELOCATION defined in my config.h. Should this be the default? edit: recompiling with -DENABLE_RELOCATION=OFF edit2: yes, that fixed it, DR is starting now.

I haven't checked the Linux build for a few days... I guess the CMakeLists need to be tweaked to include the latest changes. And the "i18n.h" needs to be included to fix the underscore error.

Last time I looked at this problem it was due to the static modulelib not having the PKGLIBDIR defined.

Can you open an issue report and attach a small example file, please?

I usually update that file when I'm getting close to a release. Good to know that this file is actually noticed by someone though.

You're welcome, thanks again for the pull request

On that topic, I wouldn't mind DR shipping a few more colour themes to choose from, if they are significantly different from the existing ones. I personally have been using the Maya/Max theme for years now, usually I just tweak one or two colours slightly if at all.

Nice!

Glad you asked, I'm running out of work anyway

Ok, great! I'll take a look then

I think that's already fixed in orbweaver's branch, I'm going to merge it. @OrbWeaverThe automake system is officially gone now, isn't it? If so, a few build instructions on the wiki will need an update.

VectorLightList is also doing a lot of reallocations (4.8% of the render footprint) - while this might be more strongly pronounced in the STL Debug build I've been profiling than it would be in a release build, I guess it'd be better to initialise the vector with a larger capacity to start with.

There's a lot of this going on, it evaluates the Light Entity AABB for every check afresh, this takes alone 5% of all time spent on all cam rendering: Also, it seems includePoint() is really expensive. That check could be refactored to check the two radii first and choose the larger one. But I think most of it can be saved by buffering the m_doom3AABB member - it doesn't have to be recalculated for each test. Maybe we don't need localAABB() at all and can use lightAABB() instead? I think that one is cheaper.

Can't spot anything huge in the profiler for the orthoview, that's dominated by the display list and patch wireframe rendering, as usual. But the camera renderer has a quite large portion of light intersection handling going on (this is not in lighting mode, just regular fullbright): Maybe that step isn't all that necessary when doing regular fullbright rendering?

To be honest, I haven't looked into performance at all. I take it that 2.8.0 or 2.9.0 didn't have these lags? It should probably be visible in the profiler, if it's that bad.

I saw this happen a lot too, the merging code is not caring about orientation as of now. The algorithm is merely looking to match up any edge of the two candidates in any direction - I guess the reversal happens in the case the code needs to flip around the other patch for its vertices to match. But I agree that if both patches are facing upwards, the result should be facing upwards too, it shouldn't counter-intuitively reverse things. It's either a bug in the code or I have to add some steps to preserve the orientation, I just need to look into it. edit: found a way to improve things, the patch orientation should be preserved now.

Thanks, glad you like it.

Here's the DR 2.10.0pre3 build for every interested mapper to test. It introduces a couple of new features that might increase the average mapper life quality. Feature: Patch Merging/Welding Feature: Maps can be opened from PK4s Selecting File > Open Map from Project... one can select a .map file that is saved in any PK4 of the current project or from a completely separate PK4 somewhere in the file system: And one can select the font size of the OrthoView grid in the preferences now: For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/1Q4iCbF--lZYu5p57GWkNM2xaI7vI8LWU/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/1rKc6ansoAY7Subf70GV5XYsyQTrl7b6D/view?usp=sharing Linux folks need to compile this stuff from source, instructions for various distributions are on the wiki. If you happen to run into a crash, please record a crashdump: How to record a crashdump Changes since 2.9.0 can be seen on the Bugtracker changelog, here's the summary: #5436: Feature request: User control of font size of "size" numbers on ortho screen #5382: Merge patch connect patches #5108: Allow DR to open .maps that are inside .pk4s #5309: Creating a model entity creates a "phantom light" near the world origin #5425: Automatic map saving can crash DarkRadiant #5097: Layer toggle controls can get out of sync (showing wrong icons) #5424: Up/down strafe movement not working in camera free look mode #5426: Can't build Radiant on current arch due to pybind breaking change #5429: EntityClassManager vs. VirtualFileSystem initialisation order might prevent .def file parsing #5430: World geometry is blue and cannot be changed when no worldspawn entityDef is defined #5442: Expose LayerManager interface to Python scripts Changes since 2.10.0pre1 #5382: Some patch welding improvements to have the merged patches face in the expected direction #5364: Light colours in the ortho view can be overridden by the colour specified in the scheme #5452: Update pybind11 version to 2.6 #5448: 16-Bit PNGs and 8-Bit Greyscale PNGs with Alpha channel can be loaded correctly (again) #5440: DarkRadiant now warns before saving in case the map file has been modified in the meantime Changes since 2.10.0pre2 #5451: Creating/renaming/deleting a layer didn't flag the map as modified #5443: Selected light bounds not updated when editing light_radius spawnarg #5406: Add dropdown list of all map entity names when editing a "Name of single entity" of an Objective component #5406: Double-clicking an objective will open the editor. Objectives Dialog will automatically select the first objective entity now. #5444: Brushes were not selectable in orthoview when none of its faces were facing upwards Thanks for testing, as always!