Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Days Won


greebo last won the day on July 5 2010

greebo had the most liked content!

Community Reputation

29 Good

About greebo

  • Rank
    Heroic Coder
  • Birthday 11/26/1979

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    conduction band
  • Interests
    Physics, Sports, Guitar, Coding

Recent Profile Visitors

12861 profile views
  1. Hm, everything sounds pretty normal to me. The wxWidgets version of your system can be seen in the Help > About dialog, but I assume it's something like 3.0.4 or 3.0.5, since the debian package is referencing those. There is a newer DR 2.9.1 package for Debian sid: https://packages.debian.org/sid/darkradiant - is this available for your distro too? Apart from those things, I don't have any idea what might be going wrong. I'd need to set up that distro of yours in a VM to check it out myself.
  2. Ok, ok. I need to know more about your setup. Which DarkRadiant version are you using, and where did you get it from? Did you compile from source? What wxWidgets version is it built against? Are there any other steps you had to perform before you got it running? This is running on an actual PC, I suppose, or are you perhaps using a virtual machine? Any warnings in the console, or the command line? I know nothing about that distribution, but if it's Debian-based, it should work in principle.
  3. It seems the crosshair is appearing in the middle of the camera view, which means that you entered the free look mode. But it seems, you aren't able to rotate the view using the mouse, is that correct? Is there something to see in the map in the first place? The ortho views seem terribly empty to me.
  4. Yes, as a last resort this is definitely an option. I'd like to avoid it as long as possible though, since it puts more maintenance work on our shoulders. Would that be even compatible or allowed with the Debian packaging? (In Windows we're indeed shipping the wx binaries along with DarkRadiant, since there's no package management - though I'm not compiling wxWidgets from source, I'm using the public releases (currently it's 3.1.3 since that includes binaries built with Visual Studio 2019). I still have to compile the libraries like libpng, libxml2, libzlib, freetype, ftgl since some of t
  5. Yeah, I even tried calling SetSashPosition(GetSashPosition() + 1) followed by SetSashPosition(GetSashPosition() - 1), but to no avail. At least there's the silver lining that wx3.1 will get published as stable release sooner or later. Rather later, since the wx team endures long intervals even between minor releases. The project is really alive (which is good for DarkRadiant), but hey, 3.1.0 was published in 2016, and now we're at 3.1.4.
  6. Added an additional Update() call in the TexturePreviewCombo and the TextureBrowser, specifically targetted at wxGTK 3.1.2 and earlier. I failed to find anything that could force an artifical size or redraw event, so I'm going to leave it at that.
  7. I tried doing it as the docs describe, calling Refresh(false) + Update() afterwards, and it changes the behaviour to be almost correct. With that refresh/update combination, the GLWidget will receive Paint events after the window resize event and it appears to work fine after overcoming this first glitch. Yes, exactly this. I compiled a debug build of wxWidgets to see where this is coming from, and after switching back from another application this is happening in the course of idle event processing. It's all bound to the "draw" event that is fired by GTK3+. The same happens when you r
  8. This appears to be pretty close. I set some rConsole output in the TexturePreviewCombo::draw() method, and it is never invoked when selecting different shaders (even though _glWidget->Refresh() is called, which should trigger an OnPaint event.) When resizing, lots of console lines are printed. I already tried experimentally changing the _glWidget->Refresh() to _glWidget->Update(), which should do an immediate paint, but this doesn't help.
  9. When using the older wxWidgets 3.0.4 in Ubuntu 20.10: problem persists Whereas in Ubuntu 19.10, where the problem doesn't occur: compiling against the newer wxWidgets 3.0.5: problem occurs I had to compile wxWidgets 3.0.5 from source in Ubuntu 19.10 and install the libgtk-3-dev package - maybe that's connected to the problem. I'll try to find out what the native Ubuntu 19.10 wxGTK 3.0.4 is compiled against. edit: the package seems to use GTK3.0, so using libgtk-3-dev should be ok.
  10. This issue has been occurring in the last few weeks, and my first thought was that it is due to a regression that happened during the code reorganisation and the necessary changes to GL context handling. In my Ubuntu 20.10 machine I walked back the git history up to the point of the DR 2.8.0 release, but as it turns out, the problem is happening there too. When switching between Media and Texture tabs, the GL widget is not refreshed, unless you resize the tabs using the splitter between cam and orthoview: So I launched my other VM running Ubuntu 19.10 and was rather surprised that t
  11. Yes, all versions share their settings, but I think in 2.9.0 it was introduced that DR saves its settings to ~/.config/darkradiant instead of ~/.darkradiant, so that might explain any difference in behaviour you might see.
  12. This is something that is observed in all Linux distros by now. I'm curious if this has been introduced in 2.9.x recently? I have to check out earlier sources and see whether this is something new.
  13. Ok, I think I got it fixed now. Here's a pre-release build, can you please give it a shot? It's a portable version, you can just extract it and use it from there. DarkRadiant 2.9.2pre2 In this version you should be able to change the brush colour and see the changes in the preview too.
  14. This is what I got: I managed to get the blue fallback colour, so I can look into a fix now.
  • Create New...