imaginaryboy
-
Posts
21 -
Joined
-
Last visited
Posts posted by imaginaryboy
-
-
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.
-
The features available via the material definitions are defined by the Doom3 engine, DarkRadiant is not in the position of changing or extending them.
Texture colours can be modified on entities whose models are using shaders with the colored keyword, using shaderparm spawnargs.
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.
-
Hm, the static_cast shouldn't be necessary. Obviously gcc isn't brave enough to implicitly convert the EntityClass* pointer to const EntityClass* here. I added an explicit constructor call to the code, does it work better now?
Btw, the layouts can be switched via the "View" menu now.
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 the notex.bmp shader, instead of the correct shader used in the previous version.
Although I kind of like having my full screen for the main window/ortho view, I'll try out the embedded view, and see how that goes.
BTW, I was curious if there are plans to support additional keywords in the .mtr files, i.e to allow setting texture colors from the editor, change the default scale, etc.
Thanks
-
The linux makefile is probably out of date, I added that missing file, but you'll be missing the whole new CommandSystem module anyway. I'll ask OrbWeaver to add a makefile for that module.
edit: OrbWeaver already updated the makefiles, it should work again now.
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 ScriptEntityClass - return GlobalEntityClassManager().findClass(name); + return static_cast<IEntityClassConstPtr>(GlobalEntityClassManager().findClass(name)); } IModelDef EClassManagerInterface::findModel(const std::string& name) {The camera rendering looks good, though.
-
Ah, sorry, I missed the underscore in one of the filenames - I can see the two files now, of course.
I checked out the map and indeed the ligthtfalloffimage doesn't get recognised, as the incoming tokens are always converted to lowercase by the parser beforehand. The case-sensitive string comparisons in MapExpression.cpp are not appropriate in this case, as the "_nofalloff" token will always be lowercase.
Also, the editor image (the one with the text "nofalloff" on it) doesn't make sense either way, so the problem should be fixed by just replacing the existing comparison with _nofalloff and point it to the correct file (the white one).
I'll check in the fix in few minutes, I think this should resolve your issue.
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()'
-
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 -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 -0 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 0 0 -1 64 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 } } // primitive 1 { brushDef3 { ( 0 0 1 -64 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 0 1 0 -144 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 1 0 0 -256 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 0 0 -1 -64 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( -1 0 0 -0 ) ( ( 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 } } // primitive 2 { brushDef3 { ( 0 0 1 -64 ) ( ( 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 -272 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 0 0 -1 -64 ) ( ( 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 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 } } // primitive 3 { brushDef3 { ( 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 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 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 -0 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 0 0 1 64 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 } } // primitive 4 { brushDef3 { ( 0 0 1 -64 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 1 0 0 -256 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 0 0 -1 -64 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 0 -1 0 -144 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( -1 0 0 -0 ) ( ( 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 } } // primitive 5 { brushDef3 { ( 0 0 1 -64 ) ( ( 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 ( 0 0 -1 -64 ) ( ( 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 -16 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 ( 1 0 0 -0 ) ( ( 0.015625 0 -0 ) ( -0 0.015625 0 ) ) "textures/base_wall/silverswatch" 0 0 0 } } } // entity 1 { "classname" "light" "name" "light_1" "origin" "128 0 0" "light_center" "0 0 0" "light_radius" "320 320 320" "texture" "lights/defaultprojectedlight" }
-
What should be the difference between the two falloff textures? There is only one "noFalloff.bmp" in the DarkRadiant bitmaps folder, and in Windows the case difference wouldn't be distinguishable anyway. There is also only one "_noFalloff" used in the D3 and TDM shaders.
Also, what do you mean with "plain white texture for the camera view"? The camera view doesn't use textures by itself - and of course nofalloff is always to be used as light falloff textures.
I think I'm missing something here?
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 (not much to see there, it's just white):
http://darkradiant.svn.sourceforge.net/vie...bmp?revision=35
Since it doesn't seem to find anything for the _nofalloff texture, it falls back to using this one to render:
http://darkradiant.svn.sourceforge.net/vie...bmp?revision=35
So tolower would eliminate the blue (from the third image) but would still have the black marks (visible in the first image). The second one is the only one that renders the way I'd expect.
-
Don't use the tag, use the latest trunk, this should compile just fine. Perhaps you'll need to run ./autogen.sh and configure, but it should work overall.
Also, please don't symlink source files to other source files - this is bound to fail.
So, I gather there is some sort of mixed-case conflict going on? If that's the case, it should rather be fixed by adding a boost::algorithm::to_lower() call in the correct places.
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 because it's using notex.bmp as the default falloff texture. My first patch improves that, but has black stripes, since _nofalloff.bmp has descriptive text, which gets distorted when rendered.
It does seem a bit odd that the cases are crossed that way; maybe something got switched somwhere. I also haven't done a side-by-side comparison to see if noFalloff.bmp is accurate, or should be closer to _nofalloff.bmp without the text. But at least the code now maps each built in texture to a distinct image file, and renders without obvious defects.
-
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::string IMAGE_POINTLIGHT2 = "_pointlight2.bmp"; const std::string IMAGE_POINTLIGHT3 = "_pointlight3.bmp"; @@ -649,6 +650,10 @@ FileLoader d(GlobalRegistry().get("user/paths/bitmapsPath") + IMAGE_NOFALLOFF); return d.construct(); } + else if (_imgName == "_nofalloff") { + FileLoader d(GlobalRegistry().get("user/paths/bitmapsPath") + IMAGE_NOFALLOFF2); + return d.construct(); + } else if (_imgName == "_pointLight1") { FileLoader d(GlobalRegistry().get("user/paths/bitmapsPath") + IMAGE_POINTLIGHT1); return d.construct(); -
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.
-
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")) { FileLoader d(GlobalRegistry().get("user/paths/bitmapsPath") + IMAGE_NOFALLOFF); return d.construct(); }I still see this in darkradiant.log:
65[shaders] Unable to load texture: _default
That's from line 65 in GLTextureManager.cpp (same as the fixed error)
-
The mainframe.cpp file has been declared "deprecated" after I merged the new MainFrame code back into trunk. The file is now called mainframe_old.cpp, but all the code you're looking for is gone anyways in the latest revisions.
You can implement a new mainframe layout by adding a new class deriving from MainFrameLayout, like it's done in the file radiant/ui/mainframe/EmbeddedLayout.h for instance.
Or by writing a custom DarkRadiant plugin for example, but this is more ambitious.
Oh, OK; maybe there's just a makefile out of sync, then; i.e. from tags/9.10
make[2]: *** No rule to make target `mainframe.cpp', needed by `darkradiant-mainframe.o'. Stop.but after symlinking mainframe_old.cpp, I get a lot of undefined references to ui::ScreenUpdateBlocker::~ScreenUpdateBl
ocker() and such.
-
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 should've mentioned that I've only used it with gnome; the floating windows don't show up in the task bar the way they do in some applications. for now I just make sure to kill them instead of iconifying, so at worst I just have to select them menu item twice to repost them.
I'd guess the behavior I'm seeing with the lights (horizontal blue stripes) is due to a problem parsing or finding one of the default textures, although I haven't looked at lighting textures enough yet to figure out more detail.
Thanks
-
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 of the other modes.
- The camera view doesn't render the defaultprojectedlight texture properly; it seems to use the "shader not found" texture in place of one of the built ins.
- It seems to ignore its command line arguments and just load an empty map. I can see where it's ignoring the arguments, but it looks like the code tries to load the previous map; I'm not sure why I'm not seeing that happen.
- Sometimes floating mode loses windows; i.e. if one is iconified, it can't be restored without restarting, if closed with the window manager, it has to be togled off, then on again to view it. I'd guess events from the window manager aren't being handled correctly.
Anyway, just thought I'd post something here, to see if any of these should/could be fixed, or if any are particularly simple.
Thanks..
Index: radiant/mainframe.cpp ======================================== =========================== --- radiant/mainframe.cpp (revision 4021) +++ radiant/mainframe.cpp (working copy) @@ -1265,6 +1265,16 @@ else if (CurrentStyle() == eFloating) { + + // Allocate a new OrthoView and set its ViewType to XY + XYWndPtr xyWnd = GlobalXYWnd().createEmbeddedOrthoView(); + xyWnd->setViewType(XY); + // Create a framed window out of the view's internal widget + GtkWidget* xyView = gtkutil::FramedWidget(xyWnd->getWidget()); + // Add this to the mainframe hbox + gtk_box_pack_start(GTK_BOX(hbox), xyView, TRUE, TRUE, 0); + + gtk_window_group_add_window(windowGroup, window); { - 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?
-
I have updated the repository with DR packages for 0.9.10 for:
* hardy 8.04 32bit
* hardy 8.04 64bit
* intrepid 8.10 64bit
Other versions can be done, but I need to setup new virtualboxes for that, so please post here if you want another OS or system version.
I could use intrepid 64-bit; I just checked the repository, and didn't see anything new for intrepid.
-
I wonder if the libs are supposed to lock the device, and share the lock. In that case, it's probably only reproduceable on a 64-bit system; maybe the different libraries aren't playing together nicely.
Do you seen any problems with just delaying opening the device until it's needed? That would help me, since I haven't needed it yet.
Index: plugins/sound/SoundPlayer.cpp ======================================== =========================== --- plugins/sound/SoundPlayer.cpp (revision 4021) +++ plugins/sound/SoundPlayer.cpp (working copy) @@ -33,6 +33,7 @@ // Constructor SoundPlayer::SoundPlayer() : + _initialized(false), _context(NULL), _buffer(0), _source(0), @@ -40,7 +41,11 @@ { // Disable the timer, to make sure _timer.disable(); - +} + +// Defered setup +void SoundPlayer::Initialize() +{ // Create device ALCdevice* device = alcOpenDevice(NULL); @@ -131,6 +136,8 @@ alDeleteBuffers(1, &_buffer); _buffer = 0; } + } else if (!_initialized) { + Initialize(); //defered intialization } _timer.disable(); Index: plugins/sound/SoundPlayer.h ======================================== =========================== --- plugins/sound/SoundPlayer.h (revision 4021) +++ plugins/sound/SoundPlayer.h (working copy) @@ -12,6 +12,10 @@ class SoundPlayer { + // Are we set up yet? Defer initialisation until we play something. + bool _initialized; + + ALCcontext* _context; // The buffer containing the currently played audio data @@ -27,7 +31,9 @@ public: // Constructor, initialises the AL utitilites SoundPlayer(); + void Initialize(); + /** greebo: Destroys the alut context */ ~SoundPlayer(); -
Do you have a 64bit distribution? I am afraid the 32bit package I build won't work then, anyway. (How did you manage to install it, btw? It shouldn't have been included in the list of possible install candidates!)
Can you please try to revert it with:
svn update -r4021
and try again? There were lately some changes, but revision 4021 should compile fine.
I figured it wouldn't hurt to try, even though there were no candidates, so I grabbed the .deb and installed with dpkg --force-architecture. Now I built my own dep from r4021, which is working OK.
BTW, is there a simple way to keep it from locking the sound device? Maybe to disable sound at runtime, or just only lock the device when it's using it?
-
Okay, the repository contains now a 32bit version of DR 0.9.9-1 for Intrepid.
In case you want to compile it for yorself, you can simple follow these instructions:
Sorry, no luck yet.
I installed the package, but it looks like it seems to have problems loading some modules; maybe I don't have enough 32 bit libs:
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
/usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgiogconf.so
/usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so
darkradiant: ../include/imodule.h:227: IModuleRegistry& module::RegistryReference::getRegistry()
: Assertion `_registry' failed.
Abort (core dumped)
I also checked out the trunk and tried building that, but only got so far:
make[3]: *** No rule to make target `mainframe.cpp', needed by `darkradiant-mainframe.o'. Stop.
make[3]: Leaving directory `/home/steve/doom/darkradiant/radiant'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/steve/doom/darkradiant'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/steve/doom/darkradiant'
make: *** [build-stamp] Error 2
-
Does the Hardy package not work on Intrepid also? I am surprised if the dependencies are that specific; normally you can use packages that are one or two distributions older than yours.
If you want to build it yourself, the easiest way is to checkout the latest SVN and run dpkg-buildpackage.
I was able to install the 64-bit hardy package, but it installed as broken. I think there were issues with one or two libs, i.e. it's linked against (from memory) libGLEW 1.3, and I only have version 1.5.
I probably could track down some older versions, but if there's going to be a binary package soon, I can wait for that rather that clutter my system. Or if there's a source package in the repo, then it shoudn't be too hard to use apt-get to grab the sources and build dependencies, but I'm still fumbling my way around dpkg, so it may be tricker for me without that.
Thanks for your help!
-
I was playing around with trying to get darkradiant to work without much success, so I thought I'd post here to see if there were other packages around.
On the wiki, there is an ubuntu repository with packages for gutsy & hardy, but nothing for intrepid, and AFAIK no source packages.
Could someone compile a new package, or at least post a source package; that may still be better than tracking down the older libraries.
Thanks
external monitor mirroring laptop monitor in Linux
in TDM Tech Support
Posted
Thanks for looking into this! If it helps, here's my system specs: