Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

I take it the previous 2.22 version they have up there is the one that broke the GL rendering, so it is no use?

 

I guess if they don't provide a Win64 build of the latest version, I can have a go at building it myself using MinGW on Windows. I seem to recall from my early experiments building DarkRadiant with MinGW that it manages to provide a fairly UNIX-like build environment without requiring too much Windows expertise.

Link to post
Share on other sites
  • Replies 1.9k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Since I've stumbled over the same issue (and even tracked a needless bugreport), I've just commited the following:   Index: def/tdm_mover_base.def ===================================================

That's a pretty ambitious project that will require almost every trick in the book. I can sort of envision how you might use fences, skyboxes, and archways to assist with compartmentalization but over

I'd say it is perfectly doable if you make it almost planar, or with only mild height differences. The images below show how I would do it:   See how the mountains and houses always block the view f

Posted Images

Nevermind, I'll be looking into this. I'll probably take this as guidance to compile the GTK+ stack from source: http://live.gnome.or...ationOfGTKStack

 

I definitely prefer VC++ over MinGW, as the latter is really, really slow (I remember that from back when I still used that in combination with scons and Eclipse...)

Link to post
Share on other sites
  • 2 weeks later...

I don't see the bug myself. Having a separate method implementation declared inline in the header is not a pattern I have ever seen before though, so I don't know for sure whether it has any compile or linking issues. I wonder if the user would still see the issue if the method body was placed inside the original declaration (which would be inline by default).

Link to post
Share on other sites

While you're looking at DR stuff, I get this segfault on shutdown after starting up in Floating layout, switching to Embedded layout and then exiting the program.

 

 

#0 0x00007ffff57e0eae in g_hash_table_unref (hash_table=0x1000000000010130) at /build/buildd/glib2.0-2.30.0/./glib/ghash.c:970

#1 0x00007ffff580f8b7 in g_slist_foreach (list=<optimized out>, func=0x7ffff57e0ea0 <g_hash_table_unref>, user_data=0x0) at /build/buildd/glib2.0-2.30.0/./glib/gslist.c:880

#2 0x00007ffff6798c63 in gtk_rc_style_finalize (object=0xaacfe30) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkrc.c:1276

#3 0x00007ffff5cba9f0 in g_object_unref (_object=0xaacfe30) at /build/buildd/glib2.0-2.30.0/./gobject/gobject.c:2746

#4 0x00007ffff67cd8c1 in gtk_style_finalize (object=0xb1023f0) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkstyle.c:636

#5 0x00007ffff5cba9f0 in g_object_unref (_object=0xb1023f0) at /build/buildd/glib2.0-2.30.0/./gobject/gobject.c:2746

#6 0x00007ffff6798b6a in gtk_rc_style_finalize (object=0xa86b650) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkrc.c:1233

#7 0x00007ffff5cba9f0 in g_object_unref (_object=0xa86b650) at /build/buildd/glib2.0-2.30.0/./gobject/gobject.c:2746

#8 0x00007ffff57d5e20 in g_datalist_clear (datalist=0x1) at /build/buildd/glib2.0-2.30.0/./glib/gdataset.c:282

#9 0x00007ffff5cba9f0 in g_object_unref (_object=0x156ed50) at /build/buildd/glib2.0-2.30.0/./gobject/gobject.c:2746

#10 0x00007ffff669b92b in gtk_box_forall (container=0x156ecc0, include_internals=<optimized out>, callback=0x7ffff6867690 <IA__gtk_widget_destroy>, callback_data=0x0)

at /build/buildd/gtk+2.0-2.24.6/gtk/gtkbox.c:1251

#11 0x00007ffff66d12ef in gtk_container_destroy (object=0x156ecc0) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkcontainer.c:1093

#12 0x00007ffff5cb7ffa in g_closure_invoke (closure=0x109cc70, return_value=0x0, n_param_values=1, param_values=0xafb7ec0, invocation_hint=<optimized out>)

at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774

#13 0x00007ffff5cc9a78 in signal_emit_unlocked_R (node=<optimized out>, detail=0, instance=0x156ecc0, emission_return=0x0, instance_and_params=0xafb7ec0) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3388

#14 0x00007ffff5cd36b1 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3003

#15 0x00007ffff5cd3852 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3060

#16 0x00007ffff6776c60 in gtk_object_dispose (gobject=<optimized out>) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkobject.c:421

#17 0x00007ffff5cbc8d0 in g_object_run_dispose (object=0x156ecc0) at /build/buildd/glib2.0-2.30.0/./gobject/gobject.c:945

#18 0x00007ffff676f926 in gtk_notebook_forall (container=<optimized out>, include_internals=0, callback=0x7ffff6867690 <IA__gtk_widget_destroy>, callback_data=0x0)

at /build/buildd/gtk+2.0-2.24.6/gtk/gtknotebook.c:4292

#19 0x00007ffff66d12ef in gtk_container_destroy (object=0xa52c620) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkcontainer.c:1093

#20 0x00007ffff5cb7ffa in g_closure_invoke (closure=0x109cc70, return_value=0x0, n_param_values=1, param_values=0xb161aa0, invocation_hint=<optimized out>)

at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774

#21 0x00007ffff5cc9a78 in signal_emit_unlocked_R (node=<optimized out>, detail=0, instance=0xa52c620, emission_return=0x0, instance_and_params=0xb161aa0) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3388

#22 0x00007ffff5cd36b1 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3003

#23 0x00007ffff5cd3852 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3060

#24 0x00007ffff6776c60 in gtk_object_dispose (gobject=<optimized out>) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkobject.c:421

#25 0x00007ffff5cbc8d0 in g_object_run_dispose (object=0xa52c620) at /build/buildd/glib2.0-2.30.0/./gobject/gobject.c:945

#26 0x00007ffff66d12ef in gtk_container_destroy (object=0xa52c4f0) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkcontainer.c:1093

#27 0x00007ffff5cb80a4 in g_closure_invoke (closure=0x109cc70, return_value=0x0, n_param_values=1, param_values=0xa8b8380, invocation_hint=<optimized out>)

at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774

#28 0x00007ffff5cc9a78 in signal_emit_unlocked_R (node=<optimized out>, detail=0, instance=0xa52c4f0, emission_return=0x0, instance_and_params=0xa8b8380) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3388

#29 0x00007ffff5cd36b1 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3003

#30 0x00007ffff5cd3852 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3060

#31 0x00007ffff6776c60 in gtk_object_dispose (gobject=<optimized out>) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkobject.c:421

#32 0x00007ffff5cbc8d0 in g_object_run_dispose (object=0xa52c4f0) at /build/buildd/glib2.0-2.30.0/./gobject/gobject.c:945

#33 0x00007ffff741c631 in Gtk::Window::~Window (this=0xa1a4c00, __vtt_parm=0x7fffe7d8c2d8, __in_chrg=<optimized out>) at window.cc:612

#34 0x00000000007c184d in gtkutil::TransientWindow::~TransientWindow (this=0xa1a4c00, __vtt_parm=0x7fffe7d8c2d0, __in_chrg=<optimized out>) at ../libs/gtkutil/dialog/../window/TransientWindow.h:13

#35 0x0000000000863bc7 in gtkutil::PersistentTransientWindow::~PersistentTransientWindow (this=0xa1a4c00, __vtt_parm=0x7fffe7d8c2c8, __in_chrg=<optimized out>)

at ../libs/gtkutil/window/PersistentTransientWindow.h:25

#36 0x00007fffe7b30b25 in ui::GroupDialog::~GroupDialog (this=0xa1a4c00, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at GroupDialog.cpp:48

#37 0x00007fffe7b30c96 in ui::GroupDialog::~GroupDialog (this=0xa1a4c00, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at GroupDialog.cpp:51

#38 0x00007fffe7b34152 in boost::checked_delete<ui::GroupDialog> (x=0xa1a4c00) at /usr/include/boost/checked_delete.hpp:34

#39 0x00007fffe7b34f84 in boost::detail::sp_counted_impl_p<ui::GroupDialog>::dispose (this=0xa259ec0) at /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78

#40 0x00000000007c1184 in boost::detail::sp_counted_base::release (this=0xa259ec0) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:145

#41 0x00000000007c11fd in boost::detail::shared_count::~shared_count (this=0x7fffffffdda8, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:217

#42 0x00000000007c4b56 in boost::shared_ptr<RadiantEventListener>::~shared_ptr (this=0x7fffffffdda0, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:168

#43 0x00000000007c32ee in radiant::RadiantModule::broadcastShutdownEvent (this=0xf67060) at RadiantModule.cpp:81

#44 0x000000000099e244 in ui::MainFrame::shutdown (this=0xf918f0) at ui/mainframe/MainFrame.cpp:516

#45 0x000000000099cb7c in ui::MainFrame::destroy (this=0xf918f0) at ui/mainframe/MainFrame.cpp:255

#46 0x00000000007c04a3 in main (argc=1, argv=0x7fffffffe058) at main.cpp:178

 

 

 

It looks like it could be a double deletion issue, but I can't think what would be causing it since AFAIK all widgets should be owned by their parents.

Link to post
Share on other sites

Ok, I get a crash too, but a different one. I'm not sure there is something I can do in the client code, I think it is a consequence of the reparent() function which is invoked to move the Gtk::Notebook object to a different parent container. On shutdown, the Notebook is destroyed and the GDK code is crashing on the notebook object when trying to recalculate the absolute position (a parent* NULL pointer is encountered and not checked for, which leads to the crash on my end - I guess this is the result of the reparenting code not doing things cleanly).

 

Does the crash happen on your end without switching layouts too, i.e. when starting in Embedded and shutting down in Embedded?

Link to post
Share on other sites
Ok, I get a crash too, but a different one.

 

Right, I think I also got a different one when I experienced the issue the first time.

 

Does the crash happen on your end without switching layouts too, i.e. when starting in Embedded and shutting down in Embedded?

 

Starting in Embedded and not doing any switching results in no crash. Starting in Embedded then switching to Regular also results in no crash, but switching from Regular to Floating gives an immediate crash (not on shutdown), with a noticeably different stack trace:

 

 

 

#0 0x00007ffff3b39886 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

#1 0x00007fffe6581826 in Toggle::updateWidgets (this=0x15762f0) at Toggle.cpp:54

#2 0x00007fffe7b51f60 in ui::ToolbarManager::createToolItem (this=0x117d948, node=...) at ToolbarManager.cpp:97

#3 0x00007fffe7b52440 in ui::ToolbarManager::createToolbar (this=0x117d948, node=...) at ToolbarManager.cpp:149

#4 0x00007fffe7b51a5f in ui::ToolbarManager::getToolbar (this=0x117d948, toolbarName=...) at ToolbarManager.cpp:45

#5 0x00000000008a0cc1 in ui::TextureBrowser::constructWindow (this=0xa3568f0, parent=...) at ui/texturebrowser/TextureBrowser.cpp:1082

#6 0x00000000009a9542 in ui::FloatingLayout::activate (this=0xb0e1660) at ui/mainframe/FloatingLayout.cpp:59

#7 0x000000000099e46f in ui::MainFrame::applyLayout (this=0xf918f0, name=...) at ui/mainframe/MainFrame.cpp:570

#8 0x00000000009a5871 in ui::LayoutCommand::activateLayout (this=0xa254ac0, args=...) at ui/mainframe/LayoutCommand.h:75

#9 0x00000000009a9097 in boost::_mfi::mf1<void, ui::LayoutCommand, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>::operator() (this=0xa2e5d10, p=0xa254ac0, a1=...)

at /usr/include/boost/bind/mem_fn_template.hpp:165

#10 0x00000000009a8909 in boost::_bi::list2<boost::_bi::value<ui::LayoutCommand*>, boost::arg<1> >::operator()<boost::_mfi::mf1<void, ui::LayoutCommand, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>, boost::_bi::list1<std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&> > (this=0xa2e5d20, f=..., a=...) at /usr/include/boost/bind/bind.hpp:313

#11 0x00000000009a821e in boost::_bi::bind_t<void, boost::_mfi::mf1<void, ui::LayoutCommand, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>, boost::_bi::list2<boost::_bi::value<ui::LayoutCommand*>, boost::arg<1> > >::operator()<std::vector<cmd::Argument, std::allocator<cmd::Argument> > > (this=0xa2e5d10, a1=...) at /usr/include/boost/bind/bind_template.hpp:47

#12 0x00000000009a7787 in boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf1<void, ui::LayoutCommand, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>, boost::_bi::list2<boost::_bi::value<ui::LayoutCommand*>, boost::arg<1> > >, void, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>::invoke (function_obj_ptr=..., a0=...)

at /usr/include/boost/function/function_template.hpp:153

#13 0x00007fffe519983b in boost::function1<void, std::vector<cmd::Argument, std::allocator<cmd::Argument> > const&>::operator() (this=0xa2e5d08, a0=...) at /usr/include/boost/function/function_template.hpp:1013

#14 0x00007fffe5198348 in cmd::Command::execute (this=0xa2e5d00, args=...) at Command.h:69

#15 0x00007fffe51952ba in cmd::CommandSystem::executeCommand (this=0x11aedc0, name=..., args=...) at CommandSystem.cpp:344

#16 0x00007fffe5194ce2 in cmd::CommandSystem::execute (this=0x11aedc0, input=...) at CommandSystem.cpp:298

#17 0x00007fffe655e889 in Statement::execute (this=0xa254a00) at Statement.cpp:30

#18 0x00007fffe655edbb in Statement::onMenuItemClicked (this=0xa254a00) at Statement.cpp:95

#19 0x00007fffe656129d in sigc::bound_mem_functor0<void, Statement>::operator() (this=0xa25a068) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787

#20 0x00007fffe65610e4 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, Statement> >::operator() (this=0xa25a060) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251

#21 0x00007fffe6560ded in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, Statement>, void>::call_it (rep=0xa25a030) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:103

#22 0x00007ffff63f9b08 in operator() (this=0xa254b88) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:440

#23 Glib::SignalProxyNormal::slot0_void_callback (self=<optimized out>, data=0xa254b80) at signalproxy.cc:95

#24 0x00007ffff5cb80a4 in g_closure_invoke (closure=0xa254400, return_value=0x0, n_param_values=1, param_values=0xb05b040, invocation_hint=<optimized out>)

at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774

#25 0x00007ffff5cca1f5 in signal_emit_unlocked_R (node=<optimized out>, detail=0, instance=0xa8313a0, emission_return=0x0, instance_and_params=0xb05b040) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3342

#26 0x00007ffff5cd36b1 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3003

#27 0x00007ffff5cd3852 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3060

#28 0x00007ffff6867fbe in IA__gtk_widget_activate (widget=0xa8313a0) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkwidget.c:5023

#29 0x00007ffff6762afd in IA__gtk_menu_shell_activate_item (menu_shell=0xa82b0a0, menu_item=0xa8313a0, force_deactivate=<optimized out>) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkmenushell.c:1353

#30 0x00007ffff6762e95 in gtk_menu_shell_button_release (widget=0xa82b0a0, event=<optimized out>) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkmenushell.c:780

#31 0x00007ffff674e828 in _gtk_marshal_BOOLEAN__BOXED (closure=0x10a0d30, return_value=0x7fffffffd990, n_param_values=<optimized out>, param_values=0xa823a00, invocation_hint=<optimized out>,

marshal_data=<optimized out>) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkmarshalers.c:86

#32 0x00007ffff5cb80a4 in g_closure_invoke (closure=0x10a0d30, return_value=0x7fffffffd990, n_param_values=2, param_values=0xa823a00, invocation_hint=<optimized out>)

at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774

#33 0x00007ffff5cc9e5f in signal_emit_unlocked_R (node=<optimized out>, detail=0, instance=0xa82b0a0, emission_return=0x7fffffffdaf0, instance_and_params=0xa823a00)

at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3310

#34 0x00007ffff5cd3483 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3013

#35 0x00007ffff5cd3852 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3060

#36 0x00007ffff6868dc1 in gtk_widget_event_internal (widget=0xa82b0a0, event=0xa84dd20) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkwidget.c:4992

#37 0x00007ffff674ca23 in IA__gtk_propagate_event (widget=0xa82b0a0, event=0xa84dd20) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkmain.c:2567

#38 0x00007ffff674cd83 in IA__gtk_main_do_event (event=0xa84dd20) at /build/buildd/gtk+2.0-2.24.6/gtk/gtkmain.c:1757

#39 0x00007ffff5f5609c in gdk_event_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at /build/buildd/gtk+2.0-2.24.6/gdk/x11/gdkevents-x11.c:2377

#40 0x00007ffff57f2a5d in g_main_dispatch (context=0x100fd70) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:2441

#41 g_main_context_dispatch (context=0x100fd70) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3011

#42 0x00007ffff57f3258 in g_main_context_iterate (context=0x100fd70, block=<optimized out>, dispatch=1, self=<optimized out>) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3089

#43 0x00007ffff57f3792 in g_main_loop_run (loop=0x10c6460) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3297

#44 0x00007ffff674bdb7 in IA__gtk_main () at /build/buildd/gtk+2.0-2.24.6/gtk/gtkmain.c:1329

#45 0x00000000007c0482 in main (argc=1, argv=0x7fffffffe058) at main.cpp:173

 

 

 

I'm not even sure if this is the same issue, unless there is something in the Floating layout code which is causing corrupted memory and the resulting undefined behaviour (perhaps the reparenting as you say).

Link to post
Share on other sites
  • 2 weeks later...

@OrbWeaver: after the recent precompiled header changes in darkmod_src I made a small experiment in the DarkRadiant codebase too. I created a single precompiled.h file which accumulates all the include/i*.h files as well as gtkmm.h. In the VC++ project settings I forced the inclusion of this file in the entire radiant/ main module, and the results are really impressive. Compilation of that module went from 260 seconds down to 44 (!) seconds. This is a huge improvement (if I only learnt about that years ago) and I'll definitely go ahead for the VC++ projects and add similar to all the plugins and modules.

 

The next logical question is: does autotools support precompiled headers? I seem to recall (while searching for the scons gch support) that autotools has some issues too with that.

 

Things to consider: there might be build breakage in Linux, if I (let's say) add a new source .cpp file to the project. In VC++ the "precompiled.h" is implicitly included, so I might not notice immediately that the Linux side still needs the regular #include directive of "math/Vector3.h" to compile without errors. One solution would be to actually add #include "precompiled.h" to all the .cpp files (either directly, or through gcc/autotools options), which might impose a build speed penalty in gcc if the precompiled header option is not really implemented - the #include order would always be correct, but your build times would probably go higher than necessary.

 

The ideal solution (for me) would be that gcc/autotools forces a "precompiled.h" header to be included in each module and use the precompiled headers option too => faster builds and less typing/worrying. If Auotools doesn't do it very well, then I'll go for the hybrid approach of using precompiled headers in VC++ only and adding regular #include directives to the .cpp files to ensure an error-free build.

Link to post
Share on other sites
@OrbWeaver: after the recent precompiled header changes in darkmod_src I made a small experiment in the DarkRadiant codebase too. I created a single precompiled.h file which accumulates all the include/i*.h files as well as gtkmm.h. In the VC++ project settings I forced the inclusion of this file in the entire radiant/ main module, and the results are really impressive. Compilation of that module went from 260 seconds down to 44 (!) seconds. This is a huge improvement (if I only learnt about that years ago) and I'll definitely go ahead for the VC++ projects and add similar to all the plugins and modules.

 

The next logical question is: does autotools support precompiled headers? I seem to recall (while searching for the scons gch support) that autotools has some issues too with that.

 

Interestingly I was looking at the same thing myself, out of curiosity. It seems that actual support for precompiled headers in autotools doesn't exist (strange given that threads asking about it date from 2003), but it is easy to add custom Make rules to the Makefile.am since everything not expanded by automake gets passed through unchanged.

 

The sticking point seems to be with the use of libtool. The requirement of GCC is that the .pch file must have been compiled with the exact same compiler flags as the .cpp file you are trying to use it with, which is easy to ensure in a simple project where you are writing all the CFLAGS yourself in a Makefile, but when libtool is used it reserves the right to add additional flags as required for shared library support, namely -fPIC on Linux. This means that it would be necessary to add the -fPIC flag manually when compiling the .pch for use with the modules, but without it when compiling the main binary (and the same .pch could not be used for both).

 

I'm sure it would be possible to get it to work, but having to manually add flags that you know libtool will happen to use, but cannot be determined with 100% certainty except by manual inspection of the generated command lines, seems a bit of a hack. Alternatively, maybe the precompiled header could be used only with the main binary on Linux, which would avoid the libtool issue but reduce the performance benefit.

 

Things to consider: there might be build breakage in Linux, if I (let's say) add a new source .cpp file to the project. In VC++ the "precompiled.h" is implicitly included, so I might not notice immediately that the Linux side still needs the regular #include directive of "math/Vector3.h" to compile without errors. One solution would be to actually add #include "precompiled.h" to all the .cpp files (either directly, or through gcc/autotools options), which might impose a build speed penalty in gcc if the precompiled header option is not really implemented - the #include order would always be correct, but your build times would probably go higher than necessary.

 

I guess the inclusion could be based on a macro, e.g.

 

#ifdef USE_PRECOMPILED_HEADERS
#include "precompiled.h"
#else
... regular includes here ...
#endif

 

If the resulting build was then tested both with and without the USE_PRECOMPILED_HEADERS macro defined, you could probably assume it was going to work on both platforms.

Link to post
Share on other sites

Yes, the macro is a possible option to avoid that kind of problem (though it might need a separate build to catch it).

 

I'm aware of the problem with re-using the same precompiled header (.gch) file for different -fPIC settings, I ran into that with the mod code too. That's why I designed it like this: each module has its own "precompiled.h", which is in turn referring to a few central "precompiled_xxxxx.h" files in the incude/ folder, e.g. precompiled_main.h or precompiled_interfaces.h. Each module can also control which precompiled_xxxxx.h files are included to avoid including stuff that requries additional libraries or other stuff.

 

In SVN there are already a few of the larger projects set up for pch use: DarkRadiant (main binary) itself, the S/R editor, the Objectives Editor, the Script module and the Entity module.

Link to post
Share on other sites
  • 3 weeks later...

I'm sure this probably has been reported before, but I'm getting consistent crashes while using the animation preview window, after a while it just freezes and crashes... So far this has been the only issue I found in the newest version.

Link to post
Share on other sites
  • 2 weeks later...

I'll try and get a screenshot tomorrow night...

 

DR1.7.0 64 bit

Win7 Home basic 64

 

When viewing models in the model viewer I get 'image degredation'. Everything starts to turn black as I zoom/rotate the object. Seems more like rotate makes it start to black out. Zoom in brings the object texture back (sometimes, sometimes makes it worse). rotating makes it start to turn black again.

Appears it might be turning black per poly as it's angular and scattered black.

 

If the model goes all black it won't come back and selecting any object with the same skin stays black, but choosing an object with another skin will bring the rendering back. Then I can switch back to original skin and it's fixed. rotating more starts the degredation all over.

Dark is the sway that mows like a harvest

Link to post
Share on other sites

The render mode of the model viewer corresponds to the render mode in the main application, so if the 3D camera is showing lights and skyboxes etc the model preview will be in full shaded mode, whereas if the 3D camera is showing fullbright textures the model viewer will do the same. I think I did manage to reproduce it a couple of times though, in lighting mode only, and it does not occur for all tests and/or models. At I guess it looks like the depth buffer is not being cleared or something.

Link to post
Share on other sites

It's hard to search for this problem in the forums as I don't really know how to describe it.. Ok: I open up DR and all views are blank. I move around create a few brushes unable to see anything. Then the view updates! it shows me the brushes I created and all. But it's mostly unresponsive, it updates randomly but it's hard to say if it's just not updating the views in real time or if it really is lagging.

 

Well, that was my best in explaining the problem :P

Link to post
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.


×
×
  • Create New...