Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Content Count

    7988
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by OrbWeaver

  1. Maybe not, it was just a guess after all. Nevertheless, I don't know how to change this. I cannot find anything in the wxWidgets documentation relating to the visibility of shortcuts in menus, nor can I find any discussion of this issue.
  2. Technically it's never required to make visportals, but if you don't, everything in front of the camera will be rendered regardless of whether it is in the same "room" or hidden behind other objects. There is no automatic culling of geometry based on "connectedness", or anything other than the manual dividing up of map geometry by placing visportals. If you want to see what is happening at the render level you can use the r_showTris cvar to enable drawing of triangle outlines.
  3. On Ubuntu I use the gnome-tweaks tool to adjust this. It's not installed by default but is available in the repository.
  4. Indeed it has. I've updated the README.md in the source tree but not the wiki.
  5. Yes, that seems plausible. We need to be careful though because there are at least two different situations where AABBs are needed — lighting calculations and the selection system — and the AABBs they need are not identical. But I'm sure there is a bit of redundancy from the legacy code that we could simplify. Also a good suggestion. We could default initialise it with a "sensible" initial light count like 16, or even try std::list which should have constant time insertions at the expense of slow random access (which is not needed). In any case, as of a8a19bec7bce6 I have disabled
  6. No, it shouldn't be necessary at all. That seems like an oversight on my part. We only need to calculate the light intersections in the lighting preview mode. Even when we are in lighting mode, that 35% worries me (since it happens in every frame). I did do some performance testing with the new lighting code, but didn't see any significant regressions. Maybe the performance characteristics are very different on Windows vs Linux.
  7. I'm pretty sure there have never been any textures shown in the 2D ortho views. Texturing simply isn't enabled in those views. I agree that patches disappearing when you look at them from behind in the 3D view is annoying. Perhaps I'll look into it; there might be some simple OpenGL state that can be set to show the patches from behind (maybe in wireframe).
  8. Something weird happened when I tested the patch welding (which overall looks like a great feature). I made two rectangular patches in the top view, welded them together and the patch seemed to disappear from the 3D view. It turns out the orientation was flipped, so I had to move the camera down and look up at it to see the texture. Is it possible that the welding code is either flipping or ignoring (resulting in undefined behaviour) the patch normals?
  9. I too am rather skeptical of an ongoing need for per-material frob customisation, but ultimately I am not a mapper and if experienced mappers say they have needed it, I can't really contradict them. Nevertheless, for the main bulk of materials which do not need per-material customisation, I don't understand what benefit a macro (which the material author must remember to manually include in every material he creates) provides over simply doing what the macro would do in the C++ code, automatically, for every material. This would not even prevent the use of customisations: the behaviour co
  10. My mistake, I thought your idea was for some kind of floating LED widget in the ortho views. Still, even custom-drawn GUIs using wxWidgets would be an additional maintenance burden, so I wouldn't recommend this unless it was really important. A regular dialog using toggle buttons with appropriate icons would be fine, I think. It's also important to remember that some users may be colour blind, so GUIs should never use only colour to distinguish important information. It's fine to use colour as an additional highlight provided there is some other change of shape/icon/text which doesn't rel
  11. As a UI programmer I'd say that stgatlov's LED idea looks nice, but I'd rather not go down the route of implementing our own custom GUIs in the OpenGL windows. Just rationalising the menu items into appropriate toggles (rather than separate Enable X and Disable X menu items) would be a big improvement, then perhaps pulling out a couple of major options into toolbar buttons so mappers could quickly enable or disable the sync with a single click.
  12. I think this might be a GTK theming issue. Clicking around through various core GNOME apps (I tried Files, Disks, Videos, Terminal and gEdit) I see no menus with shortcuts listed. All the apps have moved to the new "header bar" style where you don't actually have the regular File/Edit menu bar, just various buttons and a "Menu" button which brings down a speech bubble-style menu which does not contain any shortcuts. If this is implemented at the GTK 3 level rather than with GNOME-specific code, then I guess it applies to wxWidgets too which uses GTK 3 as a backend. In which case, I'm not
  13. Other things I particularly like about CMake in no particular order: It keeps all CPU cores occupied for the entire build, and will happily build different submodules in parallel. Automake would only ever parallelise compilation of CPP files within a single module, with each module needing to be linked before it would move on to the next one. If you adjust a compiler or linker option in a CMakeLists.txt, it automatically rebuilds whatever might be affected by that compiler option. With autoconf the configure script would be regenerated automatically but you would have to manually
  14. As of Git commit 67be9762f446d27abd84b3df49ba8cf1f4271077 we now have a functioning CMake build for DarkRadiant on Linux. The motivations for this are twofold: The main mod is using CMake already, and I am interested (at some point in the distant future) in the possibility of trying to re-use some code from the mod inside DR, in order to reduce code duplication for certain common functionality like parsing DEF files. Using the same buildsystem will make this much easier. Autotools is quite honestly an outdated and hacky buildsystem, in which you use M4 macros to generate a shell
  15. Vim does check the modification timestamp when you are about to save a file, and if it has changed since the file was read, it by default aborts and asks if you really want to continue. This is probably the easiest thing to do in DR too. This is considerably more complex to implement. I can think of two ways to achieve it: Write a lock file to the map directory when it is opened, e.g. when opening mymap.map, we also write out mymap.map.lock. If DR is asked to load a map and there is already a .lock file, it could ask if you really want to continue (but it must still give you th
  16. Can you confirm that there is something rendered in the 2D views after importing the prefab? If the 2D views are empty then there will be nothing to see in the 3D view either. Does this happen with every prefab and every model you import, or just a specific one? Is anything ticked in the Filters menu that might be hiding particular objects?
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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
  22. 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
  23. 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()
  24. 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.
  25. 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
×
×
  • Create New...