Itches, Glitches & Anything Else...

[Komag]

It seems that every time I go into fullscreen game mode with my link...

 

C:\Games\doom3\DOOM3.exe com_allowconsole 1 +set r_fullscreen 1 +set fs_game darkmod

 

and test out anything, when I exit the game and come back to Dark Radiant, all of my windows (camera, XY, Entities) have been nudged down and to the right about a centimeter. I always have to grab them and move them back up left.

 

If I don't fix them and go in game mode again, when I come back they are nudged another centimeter down right, and so on.

 

I imagine it has something to do with the changing resolutions. My desktop is 1280x800 (my laptop LCD native resolution), but I have Dark Mod set to 800x600 (so that when I do use windowed mode to test stuff it isn't too big on my desktop).

 

It's not a showstopper by any means, but it's a bit annoying.

 

PS - is there some way to turn on a skinny tall Z window like in DoomEdit? It's in the little thumbnails in "Layout" options in Preferences, but maybe those are just holdovers from DoomEdit

[greebo]

Not sure if I can do anything about that resolution change and the subsquent window moving issue, I guess that's just another GTK/Windows issue we can't solve.

 

As a workaround I'd suggest running Doom3 in windowed mode. Admittedly, the mood is not as good as in fullscreen mode, but if you're just testing things it should not be that bad.

 

Concerning the Z-window: the icons in the preferences are leftovers and have no actual meaning. Currently there is no Z-window available, I don't know if it's that useful either.

 

What do the experienced DoomEdit mappers say about the Z-window?

[sparhawk]

That's probably because of your user.xml. Please send it to greebo@angua.at so that I can make sure that your configuration gets correctly updated, as others are likely to have a similar one.

 

That's strange, because in the update there was a user.xml, and I copied everything into my directory. So the user/xml should have been overwritten.

 

On another note. I noticed that in my previous installation there are a lot of DLLs, but in the update there is none of them. So does this mean that we don't know them anymore?

 

UPS! I just deleted my directory and copied the new DR over it, and of course the DLLs are now missing. Guess I have to download 0.8.1 and then copy the new version on top of it.

[greebo]

No, the user.xml that's being shipped with DarkRadiant contains just the default values. You have a personal user.xml copy saved in your "Dokumente und Einstellungen\Anwendungsdaten\DarkRadiant" folder, which is probably conflicting with the new settings. I need this personalised copy to make sure this doesn't happen again.

 

I skipped including the DLLs in the snapshot package, they should already be in your existing DarkRadiant folder, where the package should be extracted to. They're still needed, it's just to keep the snapshot size low.

 

edit: Yes, reinstalling 0.8.1 and re-extracting the snapshot over it should do the trick.

[sparhawk]

OK. I send you my very private and personal user.xml. I hope I can attach it to a PM.

[jdude]

There's a problem with the "enable far clip plane" function in the preferences under camera. On my map the camera is lagging the editor and even when I move the camera a far enough distance away from the map so I cannot see any of it I still get lag. I don't think it is actually boosting performance by not rendering those far things like it's supposed to be.

[greebo]

I know that problem, it is part of a general performance problem of DarkRadiant. All the items in the scene are traversed several times per second which seems to be very expensive. There is not much we can do about it right now, the whole renderer/scenegraph would have to be refactored/rewritten sometime in the future if we want to improve things, I'm afraid.

[jdude]

Actually I just found something out. If you switch that option on after having it off it won't work. But if you exit then re-open the editor it works fine.

[greebo]

Any yet another weird discovery from the depths of DarkRadiant.

[SneaksieDave]

Is that right? Maybe I'm misunderstanding. I opened bonehoard and tried it both after toggling the draw plane and after setting it on and restarting. In both cases I get what seems to be the same slow behavior.

[greebo]

I'm getting a couple of these AFTER DarkRadiant shutdown (right at the return statement in main.cpp, so it is probably happening during GTK shutdown):

gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed

It must be related to some S/R Editor changes I've made during the last few days, but I don't know exactly what should cause them.

 

Any ideas of obvious things I could check? I can of course go back the SVN history and see where it first occurred, but I though I'd ask before I do that.

[OrbWeaver]

You can confirm or eliminate the SR editor quite easily by removing the plugin and seeing if you still get the error. This could also be related to the recent refactoring of the EntityInspector I did.

[greebo]

It's almost certainly related to the SR editor, because it only happens when I open the dialog. If I quit DarkRadiant without touching the dialog, the assertions are gone.

[OrbWeaver]

This error happens when you gtk_widget_destroy something more than once. The only explicit reference I can find to this function is in EffectEditor.cpp for the _argsTable, but it is not obvious whether this is the cause.

 

I don't see these messages on Linux incidentally.

[greebo]

I know, I already searched for that occurrence. Thing is, I don't even need to instantiate the EffectEditor, so that's most probably not the cause.

 

Hold on, you're right. It seems to be related to the EntityInspector. If I just open DarkRadiant and select an entity and quit afterwards the assertions appear as well. It's not the S/R Editor then, I only thought it would be as an entity has always to be selected before opening the dialog.

 

What could the cause be?

[OrbWeaver]

What could the cause be?

 

There is an explicit gtk_widget_destroy in the destructor of the PropertyEditor subclasses, this is probably resulting in the double-delete if the widget is also packed into a window at the time of shutdown.

[greebo]

2. Each DefaultConstructor has its own ImageLoaderModulesRef. This means that each of the image loader modules is instantiated and released for EVERY DefaultConstructor used (check the Radiant Console to see how much this happens when you load a large map). I tried to fix this quickly by adding a static method to return a singleton instance of the ModulesRef, but this only partially worked so this may need deeper investigation.

I reorganised the shader image constructors and introduced an ImageLoaderManager class that owns the ImageLoderModulesRef. The client classes can request a list of matching ImageLoaders from this class to do their stuff. The console flooding should be gone now.

[bob_arctor]

When you chop up brushes with X in DR it produces caulk textures whereas in D3ed it produces textures based on what the other faces' textures are.

 

The problem with all this caulking is that if you ignore it like I did you end up with holes in your level where light shines through as the back of walls are caulk which isn't rendered.

 

So I had to find all the caulk, including in nooks and crannies between walls etc, and texture it.

 

But generally you don't want caulk in your level. It's pointless (D3 removes unseen tris anyhow), and can be a problem.

 

Could the chop function not use caulk in future?

[SneaksieDave]

I think that functionality can be disabled (haven't tried it myself yet though). Look under preferences (P), clipper.

[greebo]

Go to Preferences > Clipper and tick off the "Clipper tool uses caulk texture" option.

[Fidcal]

Colour preferences : I changed Selected Brush to pale blue and Select Brush Camera to yellow but both still show as red.

 

I was trying to change it because I'm sometimes finding it difficult to read brush dimensions and coordinates and would prefer to turn that off. Can those values be read anywhere else? I can't see them on the status bar. Can they be shown on the entity inspector?

[greebo]

For some colour changes you will have to restart DarkRadiant, I'm pretty sure that the "selected brush" colour is one of them.

 

The red overlay in the camera view is a special case, I think it can't be changed at all or at least I never found the right spot to change it.

 

The brush dimensions are not shown anywhere else so far, you might want to raise a feature request on the bugtracker for this, if you feel that this should be in.

[Fidcal]

Thanks greebo - I see that now. I was happy with the selector colour anyway but thought it might change the colour of the text that shows the dimensions and coordinates which seemed to be the same red. I'll look at the bug tracker later after I give this more thought. I'm used to seeing the full properties of every selection, coords, orientation, size, texture, type, everything in one section.

 

[EDIT]

OK - forget this I now found the colour under brush vertices so I've set it bright yellow. See how I get on with that.

 

BTW I'm getting an error every time I close DR - I'll post later

[jdude]

Does Dark Radiant feature 'Parallel' lighting? I just found this tutorial, but I cannot find out how to do it in DR.

http://www.quake3bits.com/htm/tutorials/do...ing_outdoor.htm

[greebo]

Currently not. From what I see parallel lights just have the "parallel" spawnarg set to "1" and can be treated as ordinary lights apart from that.

 

Would you care to open an issue on the bugtracker?