Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16732
  • Joined

  • Days Won

    50

Everything posted by greebo

  1. Thanks, it's merged! And a new pre-release build is available in the first post.
  2. Just merged orbweavers's changes, can you please check again?
  3. 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?
  4. 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!
  5. 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?
  6. 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?
  7. 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.
  8. 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.
  9. Last time I looked at this problem it was due to the static modulelib not having the PKGLIBDIR defined.
  10. Can you open an issue report and attach a small example file, please?
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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?
  17. 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.
  18. 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.
  19. 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!
  20. If it's just appearing as point, can you confirm you've appropriately zoomed in? In the video above, I notice you're almost completely zoomed out with coordinates around 8k to 16k. That's awfully large, a prefab is usually just a few dozen units.
×
×
  • Create New...