Jump to content
The Dark Mod Forums

possible darkradiant enhancements


imaginaryboy

Recommended Posts

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);

  {

Link to comment
Share on other sites

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?

It sounds like you're describing Translate mode. Hit 'W' to toggle it on/off. You can drag in the vicinity of the arrows to constrain movement to one axis -- extremely useful. Helps you move things in one direction without moving in another, not accidentally drag vertices or distort brushes and patches, etc. I use it probably 50% of the time. If you grab out in empty space (anywhere) instead of near the arrows, you can drag the object around normally. Incidentally that's another great perk about it -- you don't have to actually touch a brush to move it around.

 

I can't really give much advice about floating mode. I used that at first, but then settled on a comfy setup in Split mode and have never looked back. :wub:

Link to comment
Share on other sites

It sounds like you're describing Translate mode. Hit 'W' to toggle it on/off. You can drag in the vicinity of the arrows to constrain movement to one axis -- extremely useful. Helps you move things in one direction without moving in another, not accidentally drag vertices or distort brushes and patches, etc. I use it probably 50% of the time. If you grab out in empty space (anywhere) instead of near the arrows, you can drag the object around normally. Incidentally that's another great perk about it -- you don't have to actually touch a brush to move it around.

 

I can't really give much advice about floating mode. I used that at first, but then settled on a comfy setup in Split mode and have never looked back. :wub:

 

Translate mode has another useful feature: You can use ALT+cursor keys to move the object from grid-line to grid-line with the keyboard :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

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?

As Sneaksie said, you're in Translate mode. Just hit W again to switch back to drag mode.

 

[*]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.

?? You probably closed one of the orthoviews, you can always create new orthoviews by selecting View > New XYView or hitting Ctrl-Alt-N.

 

Anyways, the layout system was overhauled a few weeks ago, and a new layout called "Embedded" was introduced, basically combining the properties of Floating and SplitPane view. I'm thinking about making this the default view for future releases.

 

[*]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.

Projected lights aren't correctly handled by DarkRadiant right now, this is a known issue. It will get fixed whenever somebody finds the time to implement a better renderer.

 

[*]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.

Command line arguments were indeed ignored until two weeks ago. It's possible to pass a map name in the command line arguments (as well as fs_game and fs_game_base) in more recent SVN builds.

 

[*]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.

Floating view tends to be a little itchy in Windows XP, but it behaves fine in Vista so far. Usually minimising DarkRadiant by clicking on the task bar icon and restoring it again brings back any "lost" windows.

 

Translate mode has another useful feature: You can use ALT+cursor keys to move the object from grid-line to grid-line with the keyboard :)

You can do this in "drag" mode as well, you don't necessarily need to switch to Translate mode for that.

Link to comment
Share on other sites

Projected lights aren't correctly handled by DarkRadiant right now, this is a known issue. It will get fixed whenever somebody finds the time to implement a better renderer.

 

Or when somebody with a better understanding of the mathematics fixes it in the current renderer. I had a look at this code a long time ago; it is probably a simple fix but I just don't understand enough about the calculation to figure out what it is supposed to do and what it is doing wrong.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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();

Link to comment
Share on other sites

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.

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.

 

Doh!!

 

My bad, that should be the OTHER nofalloff texture. So, with his patch it seems to work.

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Edited by imaginaryboy
Link to comment
Share on other sites

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"
}

post-3045-1235612443_thumb.jpg

post-3045-1235612461_thumb.jpg

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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()'

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

If you meant that DarkRadiant's renderer should support all the shader keywords, then yes, I certainly agree. But that's something we haven't tackled yet, as 1) writing a good renderer is rather hard and 2) there were so many other things to improve when starting off GtkRadiant that it always slipped downwards in our priority queue.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 1 reply
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...