Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by OrbWeaver

  1. This is now implemented in f7f1720bd3109909beea110ac0ed55e1d9d92bc6
  2. I'm not sure about the situation on Ubuntu 20.04, but on 20.10 which I'm currently using, it seems that libjpeg-dev depends on libjpeg-8-dev which in turn depends on libjpeg-turbo8-dev and finally on libjpeg-turbo8, which I presume has been selected as the default JPEG library instead of libjpeg62 for some reason (maybe performance). I think on all Ubuntu versions the development package to install is libjpeg-dev, which might depend on libjpeg62 on some versions and libjpeg-turbo8 on others, but developers don't generally need to worry about the precise libjpeg implementation unless they
  3. In 737a8ae0dd67a463109fb4c8b73062a2f1fbd1fb I am now writing out the relative library path from CMake into config.h and using this to load the modules instead of a hard-coded relative path. I've tested by manually editing CMakeCache.txt to use "lib64" as the library directory on Ubuntu, and the installed software still works, so I'm slightly more confident that this should fix the issues on distros that use lib64 by default.
  4. Damn, just when I thought I'd found the last hard-coded lib. Yes I think you're right, we need to be passing the relative path in as a #define in config.h rather than having directories written into the source.
  5. In Git commit 5ae45caff3147b8baf99ea0917b0068a62d79752 I've added ZLIB as a link dependency when building the radiantcore module, which hopefully will fix this problem. Since I don't see the issue on my system (it looks like linking with libpng automatically includes -lz as well) I can't guarantee that this will be the only place that linking with ZLIB is needed, but any other issues ought to be similarly easy to fix.
  6. Thanks. Definitely no -lz in there, which looks like a deficiency in the CMakeLists. We are not explicitly linking against ZLIB, which probably worked fine on my system because some other library was including it by default but for some reason this doesn't happen on your system.
  7. I think you've run into the same problem that MirceaKitsune had: CMake installing things into lib64 whereas the relative rpath baked into the binary expects lib. I'm hoping it's fixed in my latest master. I'm open to suggestions regarding which should be the default. Both options should work seamlessly in most situations (at least once the currently-reported problems are fixed) and the average user probably won't notice or care much about the difference, but there are edge cases where each one would be more appropriate. ENABLE_RELOCATION=ON will build something more like the Windo
  8. I'm hoping this is fixed in bf5eaaa9264d176362a0d1abf9d5071bdbaa7959
  9. Could you please post the error using verbose make, i.e. make VERBOSE=1 We don't need the whole build log, just the part where it tries to link the problematic library (which will probably say something like "Linking CXX shared module libradiantcore.so").
  10. Although I don't think it's the cause of the problem, I don't recommend using the install directory as the destination for your build. install is not a destination directory, it's a source tree full of the resources, XML files and scripts which need to be copied into the final installation location. Having both the source files and the destination tree in the same directory is confusing and there is no guarantee there won't be some conflict between a source file and some file created by the make install step (which will just silently overwrite whatever is there). It's much better to have the f
  11. @MirceaKitsunePlease can I see the output of: objdump -p /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/darkradiant ldd /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/darkradiant find /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install cat config.h (in the top of the source directory, after running CMake)
  12. If that's the only problem, it's not a bug. DR is not intended to be runnable from the build directory without the make install step. I've added a note to the bugtracker issue accordingly.
  13. I've never seen in-game selection of MSAA samples work on Linux. I guess it's a driver issue. The super-sampling AA (r_fboResolution > 1) works fine, although it's heavy on performance.
  14. I see the problem. This was actually working when I first switched to CMake because PKGLIBDIR wasn't defined, so it would default to the runtime data path (/usr/share/darkradiant) + scripts using the same logic as on Windows. I've fixed this to always use ApplicationContext::getRuntimeDataPath which should work correctly on both Windows and Linux, and already takes into account whether it is a relocatable build or one using hard-coded absolute paths.
  15. I'm happy to work on this one assuming @greebo hasn't started on it himself. I also preferred the single-colour light volumes so I would definitely like an option to disable the per-light colouring, and this ought to be pretty easy to implement.
  16. Sure, I don't run whatever distro uses PKGBUILD so I never touch it myself, but I'll accept patches.
  17. Blender doesn't. I can make a cube or a sphere, move the camera inside, and still see all of the geometry from the inside even though the normals are facing outwards. And I'll bet that even modelling apps that hide back-facing polygons by default will still allow you to see those polygons in wireframe mode, but even this option isn't available with the current DR renderer. If you are behind a patch, you can't see it at all no matter what rendering options you select, which is really poor usability. Maybe in the lighting preview mode (which most people don't use) it's fine to show the patc
  18. Yes, that looks pretty conclusive, and suggests that @stgatilov's theory is correct. The engine is indeed dividing the map into disconnected regions separated by opaque volumes, and culling everything not reachable from the current room, without any need for visportals.
  19. Me too. I rarely bother to customise colours (I trash my preferences far too often to make lots of changes), but other than Maya/Max and Super Mal all of our themes are basically variants of hideous white. It would be great to have a wider selection of attractive themes that are actually being used by mappers.
  20. Right, but my point is that the distant room appearing to disappear behind a wall doesn't prove that it is being culled by the engine. It might still be sent to the GPU and rendered, but hidden from the final output image because something else (the wall) is drawn in front. That's why you need r_showTris 2, which shows all triangles that are being rendered, even those which are behind other objects and not visible in the final image.
  21. I know the flood fill can start with any entity, but does it actually do a separate flood fill for every entity and divide the map into visleafs if the map sections are disconnected? If so, then I guess what HMart wants to do will work perfectly.
  22. Sorry, I can't see what's happening from that video. All I see is a distant room flickering on a completely black background; I can't see what is being rendered or sent to the GPU (since r_showTris is turned off, noclip doesn't provide any information about render culling, and I can't even see if you are behind or in front of another wall since everything else is completely dark). If you want to definitively see what geometry is being sent to the GPU, you need to use r_showTris 2. Without this option, there is no way to tell the difference between something not being rendered at all, and
  23. I'm 99% sure that they won't, and that the "opaque nodes" reference only refers to the flood-filling algorithm, not the division of the map into visleafs. What it means is that the inside of a sealed box will be completely optimised away by the flood-filling algorithm, because the walls are opaque and they stop the flood-filling (which only covers parts of the map reachable from the player start). This also suggests that with HMart's unconnected rooms idea, the problem will be that most of the rooms will be considered unreachable (opaque) and optimised out by the dmap compiler. Nothing in
  24. No. If there are no visportals, there are no visleafs. The whole map is a single visleaf, and the whole thing will be rendered as long as it is in front of the camera (I assume the engines culls everything behind the camera or out of view, regardless of visportals). I think you're getting confused by the name "visportal", since the "portal" part suggests it's just a gateway between two things. From this it might follow that a map full of completely unconnected rooms wouldn't need any portals (because there are no doors or gateways between them). But the engine does not work this way. Visp
  25. This is implemented in e649657d774fc05b. I actually removed Light::intersectsAABB entirely; now all of the intersectsLight methods just do a simple AABB intersection test between Light::lightAABB and Node::worldAABB, which is much cheaper than the complex long-winded code in Light::intersectsAABB. I now see relatively little time spent in the lighting intersection calculation, and a much larger amount of time spent in the backend render method of Winding. I suspect this could be improved by the use of OpenGL VBOs to store the winding data, rather than submitting it repeatedly using s
  • Create New...