Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About imaginaryboy

  • Rank
  1. Thanks for looking into this! If it helps, here's my system specs: System: Host: inspiron Kernel: 5.3.0-45-generic x86_64 bits: 64 compiler: gcc v: 7.5.0 Desktop: MATE 1.22.2 wm: marco dm: LightDM Distro: Linux Mint 19.3 Tricia base: Ubuntu 18.04 bionic Machine: Type: Laptop System: Dell product: Inspiron 5379 v: N/A serial: <filter> Chassis: type: 10 serial: <filter> Mobo: Dell model: 0T8VVT v: A00 serial: <filter> UEFI: Dell v: 1.9.0 date: 06/12/2018 Battery: ID-1: BAT0 charge: 35.1 Wh condition: 35.1/4
  2. I just downloaded TDM for Linux. When I start it, it forces my external display to mirror my laptop display, then displays the game on both monitors, with one somewhat distorted due to it having the wrong aspect ratio. Even after the quitting the game, it leaves the display setting to display the same image on both screens, which I have to fix manually. Ideally, I'd prefer it only play on the external display without needing to disable the built in.
  3. Doom3 does support those features already; it's just tricker to use them since you wind up with textures that render completely differently in doom vs. dr. But no big deal on that, I was just curious if those are going to be implemented independently, or wait for doom to be open source or whatever. Anyway, the only regression I see in this version in that model rendering issue.
  4. Yes, that compiles fine with gcc now, and I can use the view menu. I do notice two new issues when I run it, though. When I change views, it changes it on the program while it's running with various odd results; sometimes extra widgets get superimposed over the interface, other times it looks fine, but doesn't respond to keyboard imput. The exact behavior seems to depend on which view is used before & after the change; restarting DR clears it up. When rendering in the camera view, without rendering the lights (the simpler camera view) most, but not quite all of the models use th
  5. I got it to compile by static_casting away a const-correctness problem, but the preferences window is empty, so I couldn't enable the embedded mode. I'm not sure if that's related. Index: plugins/script/interfaces/EClassInterface.cpp ======================================== =========================== --- plugins/script/interfaces/EClassInterface.cpp (revision 4282) +++ plugins/script/interfaces/EClassInterface.cpp (working copy) @@ -6,7 +6,7 @@ ScriptEntityClass EClassManagerInterface::findClass(const std::string& name) { // Find the eclass and convert implicitly to ScriptEntity
  6. OK, that makes sense; so we use the render texture now, save the other for some future enhancement to the light inspector. The trunk doesn't seem to compile now; I'll try again later. /home/steve/doom/darkradiant-0.9.10/darkradiant/radiant/log/Console.cpp:21: undefined reference to `ui::CommandEntry::CommandEntry()'
  7. I've made a few screen grabs that may help. def.jpg is how darkradiant renders a test map by default; fix.jpg is what it looks like after my fix. I've also included the source of the map, to help anyone see how it looks for them. Version 2 // entity 0 { "classname" "worldspawn" "editor_drLastCameraPos" "0 0 0" "editor_drLastCameraAngle" "0 0 0" // primitive 0 { brushDef3 { ( 0 0 1 -80 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 0 1 0 -128 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 1 0 0 -256 ) ( ( 0.015625 0
  8. Hmm, maybe windows does something different, so nobody else is seeing this behavior. There is an _ in one file name, so windows could still distinguish them that way. The other is apparently an internal string to reference something built-in, so filename case insensitivity shouldn't cause a problem there. If it helps, I can show you the to textures. This is the texture for the editor, which is not used in the camera render. http://darkradiant.svn.sourceforge.net/vie...p?revision=2056 And this is the one I'm using for the render, which currently doesn't seem to be used by darkradiant (n
  9. That was my first thought (what I did in the first patch) but it seems like that was wrong; there really are two different textures. _noFalloff -> _nofalloff.bmp is an editor texture; it should be used in the light inspector, although that doesn't seem to display falloff textures. But that mapping is correct in the current version. _nofalloff -> noFalloff.bmp is a plain white texture for the camera view. This doesn't seem to be referenced anywhere in the code, but adding that mapping as I did seems to fix the rendering problems I was seeing. As I suspected, the blue stripes are b
  10. Doh!! My bad, that should be the OTHER nofalloff texture. So, with his patch it seems to work. Index: shaders/MapExpression.cpp ======================================== =========================== --- shaders/MapExpression.cpp (revision 4021) +++ shaders/MapExpression.cpp (working copy) @@ -25,6 +25,7 @@ const std::string IMAGE_FLAT = "_flat.bmp"; const std::string IMAGE_FOG = "_fog.bmp"; const std::string IMAGE_NOFALLOFF = "_nofalloff.bmp"; + const std::string IMAGE_NOFALLOFF2 = "noFalloff.bmp"; const std::string IMAGE_POINTLIGHT1 = "_pointlight1.bmp"; const std::s
  11. Turns out the _default error is because _default.bmp is missing, but adding that (copied from white.bmp) suppresses the error but doesn't seem to help the black stripes. So I guess they're not related.
  12. Apparently, the blue & black stripes in the projected light are cuased by two different things. I found where the blue ones are coming from; maybe the black are something similar. Index: MapExpression.cpp ======================================== =========================== --- MapExpression.cpp (revision 4021) +++ MapExpression.cpp (working copy) @@ -645,7 +645,7 @@ FileLoader d(GlobalRegistry().get("user/paths/bitmapsPath") + IMAGE_FOG); return d.construct(); } - else if (_imgName == "_noFalloff") { + else if ((_imgName == "_noFalloff") or (_imgName == "_nofalloff
  13. Oh, OK; maybe there's just a makefile out of sync, then; i.e. from tags/9.10 but after symlinking mainframe_old.cpp, I get a lot of undefined references to ui::ScreenUpdateBlocker::~ScreenUpdateBl ocker() and such.
  14. OK, now that I know more about translate mode, it seems like it would be pretty useful. Before, svn was hanging on my when I tried to upgrade. Now that seems to be working, but I can't find mainframe.cpp, either in tags/0.9.10 or rev 4132. I tried creating a new ortho view, but that popped up another window, so I had to jump back & forth between the main window & the ortho view, until I combined them in the code. It sounds like your embedded mode may be similar to what I'm using now - main window with toolbars & ortho, with floating windows for the rest. Thoush I probably sh
  15. Now that I've been using dark radiant for awhile, I ave a few questions/suggestions. Sometimes when I select a brush, it shows a light blue box with some vectors, and only allows moving it in one direction; to move the brush in the other direction, I have to restart darkradiant. Is it obvious to someone who knows more than I do what I'm doing wrong? In the floating interface, the main window has big toolbars on the top & left, but just a big empty space instead of an ortho view, so I have to manage two big windows. I was able to fix this by mostly cut & pasting a few LOC from one
  • Create New...