DarkRadiant 1.2.2 released

[greebo]

The next stable DarkRadiant version 1.2.2 is available. No new major features were added to this version, but a couple of crashes were fixed. This version also features a new preference option to disable Windows desktop composition. (That, and some minor improvements and some backend code changes which shouldn't be noticeable by end-users.) Grab it from our project website:

 

http://darkradiant.sourceforge.net/

 

Important: if you haven't installed DarkRadiant before, be sure to install the VC++ 2008 Redistributable Package in order to run this release.

 

The list of changes can be found on the website: Changes since 1.2.1 and on our bugtracker changelog.

 

As usual, please report any bugs or feature requests here in these forums, following these guidelines:

• Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask.
• Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker.

As probably not everybody is reading the changelogs, here it is for reference:

 

New Features / Changes

 

• Added preference for disabling Windows desktop composition.

Bugfixes

 

• Fixed: Nurbs dio not set focus when switching views.
• Fixed: Most recent keystroke remembered when autosaving.
• Fixed: Inverting a Patch matrix didn't update the camera views.
• Fixed: Entity/Patch/Brush creation not being created at position of last selected entity.
• Fixed: Crash in Octree code when undoing brush-to-light conversion.

Tweaks

 

• "Update Views on Camera Movement" setting is disabled by default now.

Coding / Internal Design

 

• Moved ModelPreview classes to UI Manager module
• Refactored function object framework.
• Updated Win32 boost libraries to version 1.42.

[Bikerdude]

"Update Views on Camera Movement" setting is disabled by default now.

 

ta.

[aidakeeley]

Congrats.

[Neb]

greebo, just a little thanks here for all the hard work you put into Dark Radiant. 

[greebo]

Thank you, Neb.

[vlad]

There are problems in Linux with r5533.

 

First of all, it doesn't build by default. Modules don't see GTK I18N headers and libs. I built DR only when I changed some Makefile.am files like that (here comes a patch):

 

 

 

diff --git a/darkradiant/plugins/entity/Makefile.am b/darkradiant/plugins/entity/Makefile.am

index 05fde17..c994fd7 100644

--- a/darkradiant/plugins/entity/Makefile.am

+++ b/darkradiant/plugins/entity/Makefile.am

@@ -1,9 +1,9 @@

-AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/libs $(XML_CFLAGS)

+AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/libs $(XML_CFLAGS) $(GLIB_CFLAGS)

 

modulesdir = $(pkglibdir)/modules

modules_LTLIBRARIES = entity.la

 

-entity_la_LDFLAGS = -module -avoid-version $(GL_LIBS)

+entity_la_LDFLAGS = -module -avoid-version $(GL_LIBS) $(GTK_LIBS)

entity_la_LIBADD = $(top_builddir)/libs/math/libmath.la \

$(top_builddir)/libs/scene/libscenegraph. la

entity_la_SOURCES = origin.cpp \

diff --git a/darkradiant/plugins/filetypes/Makefile. am b/darkradiant/plugins/filetypes/Makefile. am

index 5fac441..6649da0 100644

--- a/darkradiant/plugins/filetypes/Makefile. am

+++ b/darkradiant/plugins/filetypes/Makefile. am

@@ -1,8 +1,8 @@

-AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/libs

+AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/libs $(GLIB_CFLAGS)

 

modulesdir = $(pkglibdir)/modules

modules_LTLIBRARIES = filetypes.la

 

-filetypes_la_LDFLAGS = -module -avoid-version

+filetypes_la_LDFLAGS = -module -avoid-version $(GTK_LIBS)

filetypes_la_SOURCES = FileTypeRegistry.cpp

 

diff --git a/darkradiant/plugins/grid/Makefile.am b/darkradiant/plugins/grid/Makefile.am

index ed9d502..5a70071 100644

--- a/darkradiant/plugins/grid/Makefile.am

+++ b/darkradiant/plugins/grid/Makefile.am

@@ -1,8 +1,8 @@

-AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/libs $(XML_CFLAGS)

+AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/libs $(XML_CFLAGS) $(GLIB_CFLAGS)

 

modulesdir = $(pkglibdir)/modules

modules_LTLIBRARIES = grid.la

 

-grid_la_LDFLAGS = -module -avoid-version

+grid_la_LDFLAGS = -module -avoid-version $(GTK_LIBS)

grid_la_SOURCES = Grid.cpp

 

diff --git a/darkradiant/plugins/undo/Makefile.am b/darkradiant/plugins/undo/Makefile.am

index bee1b50..78ee532 100644

--- a/darkradiant/plugins/undo/Makefile.am

+++ b/darkradiant/plugins/undo/Makefile.am

@@ -1,8 +1,8 @@

-AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/libs $(XML_CFLAGS)

+AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/libs $(XML_CFLAGS) $(GLIB_CFLAGS)

 

modulesdir = $(pkglibdir)/modules

modules_LTLIBRARIES = undo.la

 

-undo_la_LDFLAGS = -module -avoid-version

+undo_la_LDFLAGS = -module -avoid-version $(GTK_LIBS)

undo_la_SOURCES = UndoSystem.cpp

 

 

 

 

But this DR build doesn't work. When I try to open file or add some object, it crashes with a message:

 

terminate called after throwing an instance of 'boost::exception_detail::clone_impl< boost::exception_detail::error_info_injector< boost::bad_weak_ptr> >'

what(): tr1::bad_weak_ptr

 

Now I use r5437; it works good.

[Bikerdude]

keep getting random lockups, so reverting to 1.2.1 to see whats what.

 

[plasticman]

Now I use r5437; it works good.

Thanks for saving the day.

 

I was able to build this in a 32bit Ubuntu-VM, transfer the packages to my "real" system and FINALLY got rid of DR 1.1.0!

 

Now I can select multiple brushes even with other brushes behind them without having to reboot to windows. Isn't life beautiful again?

 

[greebo]

Thanks for the patch. I didn't watch out for posix build issues so far, rebooting into Linux is always such a hassle that I tend to avoid it as long as I can.

[greebo]

But this DR build doesn't work. When I try to open file or add some object, it crashes with a message:

 

terminate called after throwing an instance of 'boost::exception_detail::clone_impl >'

what(): tr1::bad_weak_ptr

 

Now I use r5437; it works good.

Is 5437 the latest revision you can get to work? Or is there possibly a later revision which is working as well?

[vlad]

Is 5437 the latest revision you can get to work? Or is there possibly a later revision which is working as well?

 

It is the latest version that works on my PC, but I didn't try EVERY later revision.

All later revisions that I built terminate with that boost exception.

This exception appears before i18n branch.

 

I can build some post-5437 trunk revisions and watch for exception if you want.

[greebo]

I'd appreciate it if you could compile a few spot tests and tell me in which range things started to go wrong for you. It's arguably best if you choose a revision in the middle between 5437 and HEAD and then start to divide the revision intervals by two.

[OrbWeaver]

It's arguably best if you choose a revision in the middle between 5437 and HEAD and then start to divide the revision intervals by two.

 

At the risk of sounding like a DVCS bore, both git and Mercurial have a "bisect" function which automatically finds the revision which introduces (or fixes) a bug, based on an automated test which you can provide, which in theory should make this kind of thing much easier.

 

Looking at vlad's patch it appears that he's using git-svn, so he can probably do this anyway.

 

If I get time when I get home I will see if I can reproduce this issue on my Linux system; I haven't actually tested since you merged the i18n branch back into trunk.

[vlad]

Looking at vlad's patch it appears that he's using git-svn, so he can probably do this anyway.

 

 

I've just started to search for the first bad revision.

There is one small issue in the latest revision (5536): Makefile.in files are rather old, there aren't any references to radiant/log/GtkLogRedirector.cpp in radiant/Makefile.in. So build scripts should be regenerated with autoconf/automake, and only after that DR can be built.

 

One more question: What's wrong with dm.editing plugin in Linux?

[OrbWeaver]

I've just started to search for the first bad revision.

There is one small issue in the latest revision (5536): Makefile.in files are rather old, there aren't any references to radiant/log/GtkLogRedirector.cpp in radiant/Makefile.in. So build scripts should be regenerated with autoconf/automake, and only after that DR can be built.

 

I have now rebuilt the makefiles and DR compiles, but I see the crash you mention as soon as I load a map.

 

One more question: What's wrong with dm.editing plugin in Linux?

 

It is not currently included in the build, but I don't know anything about it otherwise. I haven't been keeping abreast of all the new features Greebo has added.

[vlad]

I've just finished bisecting

The first bad revision is 5446 (Refactored entity KeyObservers into proper classes.)

[greebo]

Thanks for pinpointing the revision, vlad.

 

I can reproduce the issue in Linux, it seems I have a duplicate inheritance from boost::enable_shared_from_this somewhere. Strangely enough, this seems to work ok in VC++, but not in gcc. I have to figure that out, in the worst case I have to back away from the boost::enable_shared_from_this template, but there should be a workaround (I could try dynamic_casting the shared_ptr returned by base class' enable_shared_from_this<:node>, let's see).

 

I'll also try to get the dm_editing plugin up and running for Linux, hopefully this is not too much trial and error.

[greebo]

Vlad, I committed a fix to SVN, removing a superfluous enable_shared_from_this inheritance. Can you test this build once again? (I'm at work, I don't have Linux here.)

[vlad]

Vlad, I committed a fix to SVN, removing a superfluous enable_shared_from_this<> inheritance. Can you test this build once again? (I'm at work, I don't have Linux here.)

 

I'm at work too, and there is no doom3 and there are old boost libraries here. I can try to build it if I have free time, but probably I'll be able to build only at home.

[greebo]

No problem, take your time. Whoever gets to it first posts the result here.

[vlad]

I've built the last revision.

 

I can create brushes, but can't create entities or open maps -- DR crashes with segmentation fault.

 

Some logs may be useful.

crash at entity creation:

 

 

==7336== Process terminating with default action of signal 11 (SIGSEGV)

==7336== Access not within mapped region at address 0x0

==7336== at 0x130F5345: ModelKey::modelChanged(std::string const&) (ModelKey.cpp:44)

==7336== by 0x1310A318: entity::KeyObserverDelegate::onKeyValueChanged(std: :string const&) (function_template.hpp:1013)

==7336== by 0x1313ECAD: entity::EntityNode::addKeyObserver(std::string const&, KeyObserver&) (KeyObserverMap.h:86)

==7336== by 0x13120AA2: entity::EclassModel::construct() (EclassModel.cpp:55)

==7336== by 0x13123F91: entity::EclassModelNode::construct() (EclassModelNode.cpp:33)

==7336== by 0x13127411: entity::Doom3EntityCreator::getEntityForEClass(boost: :shared_ptr<IEntityClass> const&) (EntityCreator.cpp:64)

==7336== by 0x13127AB5: entity::Doom3EntityCreator::createEntity(boost: :shared_ptr<IEntityClass> const&) (EntityCreator.cpp:86)

==7336== by 0x742F6B: entity::createEntityFromSelection(std::string const&, BasicVector3<double> const&) (entity.cpp:143)

==7336== by 0x59BB7B: ui::OrthoContextMenu::callbackAddEntity(_GtkMenuItem*, ui::OrthoContextMenu*) (OrthoContextMenu.cpp:417)

 

 

 

crash at file opening:

 

 

 

==7413== Process terminating with default action of signal 11 (SIGSEGV)

==7413== Access not within mapped region at address 0x0

==7413== at 0x1491958D: model::PicoModelLoader::loadModel(std::string const&) (PicoModelLoader.cpp:52)

==7413== by 0x765E55: model::ModelCache::getModelNode(std::string const&) (ModelCache.cpp:140)

==7413== by 0x130F534A: ModelKey::modelChanged(std::string const&) (ModelKey.cpp:44)

==7413== by 0x13146313: entity::Doom3Group::modelChanged(std::string const&) (Doom3Group.cpp:358)

==7413== by 0x1310A318: entity::KeyObserverDelegate::onKeyValueChanged(std: :string const&) (function_template.hpp:1013)

==7413== by 0x1316ABB6: entity::KeyValue::attach(KeyObserver& ) (KeyValue.cpp:32)

==7413== by 0x13143190: entity::KeyObserverMap::onKeyInsert(std:: string const&, EntityKeyValue&) (KeyObserverMap.h:131)

==7413== by 0x131396A7: entity::Doom3Entity::notifyInsert(std::string const&, entity::KeyValue&) (Doom3Entity.cpp:219)

==7413== by 0x1313B923: entity::Doom3Entity::insert(std::string const&, boost::shared_ptr<entity::KeyValue> const&) (Doom3Entity.cpp:257)

==7413== by 0x1313BBB1: entity::Doom3Entity::insert(std::string const&, std::string const&) (Doom3Entity.cpp:284)

==7413== by 0x144A7C41: map::NodeImporter::createEntity(std::map< std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > const&) (NodeImporter.cpp:219)

==7413== by 0x144A9C86: map::NodeImporter::parseEntity() (NodeImporter.cpp:260)

 

 

[greebo]

I've had that too, but I could fix that (after some painful debugging) by setting a special gcc compilation flag on the GlobalModelCache() function. Does it still happen when you update from SVN?

 

It's a very strange occurrence and it only happens with this single accessor (GlobalModelCache()) and only when called from specific modules (both debug and release builds). We have dozens of these accessors and all of them worked fine until recently. GCC seems to do something very special here. If I "inline" the function by hand at the calling function (just like the compiler should do it), it's working fine. If I remove the "static" keyword, it's also working fine, so there really is something happening at compiler-level in this specific instance. The C++ specification is rather clear about having static objects in inline functions (it's possible and it's not undefined) but GCC seems to mess that one up. I haven't studied the generated assembly yet.

 

Let me know if the SVN HEAD works for you.

[Serpentine]

Is it using builtins and what -O level are you using? sounds a bit odd.

[greebo]

It occurs both in debug (-O0) and release (-O2) builds. It is indeed odd.

[Bikerdude]

keep getting random lockups, so reverting to 1.2.1 to see whats what

Well I carried on using 1.2.2 and all is fine, so i can only assume it was windows being a shit as I may have been trying to do too many things at once - although I wouldn't call running DR, DM3 and streaming MP3 radio doing to many things at once on my system...

 

Qx9650@3.4ghz

4GB_DDR2-1066

Edited April 23, 2010 by Bikerdude