You need to find a place to mirror this thing, 19kb/s download speed is a little too "nostalgic" for my tastes. ;) 

Or it's a fluke, but most probably it's just a temporary thing. 

The binary produces the following error on my Ubuntu 12.04 32 bit:

jonas@gjallarbru:/opt/TrenchBroom$ ./TrenchBroom
../src/unix/glx11.cpp(87): assert "xid" failed in SetCurrent(): window must be shown

(TrenchBroom:28246): Gtk-CRITICAL **: IA__gtk_window_resize: assertion `width > 0' failed
Segmentfejl

I have wxwindows 2.8.12. There is something about this error in the wxwidgets forum here:

http://forums.wxwidgets.org/viewtopic.php?t=29948&p=128726

I'm almost curious enough to compile it myself now. :-s 

wxwindows... wxwidgets of course. 

I compiled my own debug binary of TB now. Same error.

Some thoughts:

Why does the Linux Build.txt instruct us to compile our own version of WxWidgets (twice)?

Also, and I found this interesting -- have you ever tried running Linux TB through Valgrind? The output is remarkable. 

I have seen that error before, but mostly on virtual machines. It is related to a hidden window that I use to set up some shared resources for the renderer(s). What card / driver are you using?

TrenchBroom requires wxWidgets 2.9.4. 2.8 doesn't work. Since there's no official package repository yet for 2.9.4, you need to compile it yourself.

I haven't rund TB through Valgrind because I didn't want to drown in a sea of false positives. TB uses a custom allocator for many classes that speeds up memory allocation a lot, but this leads to false positives. I know from inspecting that TB doesn't have big memory leaks. In fact, I couldn't find a single leak in the current build. 

that it doesn't have leaks. I'm sure it does - just no biggies as far as I can say. I'll run it through VG anyway.

Also, "the output is remarkable" - how you just tell me what you see instead of making me guess ;-) 

jesses 

Can you be more specific when you say "run through Valgrind"? Which tests did you run? 

I just ran the standard test - mainly because I wanted to see if it came up with more info about the error message. I was a bit amazed at the sheer amount of output and the final error count it reported. If you say most of that is false positives, I'll take your word for it but it looked pretty crass.

The wxwidgets compile is pretty lengthy and, especially since we're instructed to do it twice, acts as a bit of a hurdle if someone just wants to try the editor. 2.8.12 is reported to be the official stable version so I wondered if using the dev version is strictly necessary. Apparently it is.

I use a Geforce 6 series card with Nvidia blob 304.64. 

What's the "standard test"? Valgrind typically reports lots and lots of problems. If it was a memory leak test, there will be many false positives, yeah. If it was a cache grind test, then it will moan a lot too because TB's codebase is not optimized for such things (it's just not necessary).

TB requires wxWidgets 2.9 because that has much better support for Mac OS X.

I'll see what I can do about the error message. 

The current build runs on my machine, which also has an NVidia card (it's a MacBook Pro). I'm also running Ubuntu 12.04 with the "version current" NVidia driver. How do I find out which version of the driver I am running? 

How exactly did you run Valgrind? From Code::Blocks? 

In the Nvidia control panel, accessible from the systems submenu (not sure what it is in English), you can find your driver version. I got mine from the Nvidia site, after something necessitated a driver upgrade, instead of it being the default-provided Ubuntu driver.

I simply ran valgrind ./TrenchBroom. So it would have been the memory check.

Granted, a lot of it probably is from wxwidgets or GTK, too. 

 

It crashes with 4K errors? 

has nothing to do with what Valgrind is reporting. I have looked at it, and most of the errors are within the libraries. It reports quite a bit of errors related to uninitialized variables, but these are usually due to how OpenGL works:

GLint textureId;
glGenTextures(&textureId, 1);

Valgrind will moan about this, but it's not actually in error. It's an easy fix to shut VG up, though:

GLint textureId = 0;
glGenTextures(&textureId, 1);

In any case - Valgrind won't help you finding the problem that you're seeing. That's not really a programming error but a flaw in how I set up the OpenGL context. I'll have to find a different way. 

LIBGL_ALWAYS_INDIRECT=1
should remove all false positives associated with opengl dma use.
which should actually make valgrind usable with such programs. 

just finished up recording the first in a series of TB tutorial videos (yes, you get to hear my basso gravelly northern english accent)... They're not properly finished yet (needs a bunch of tweaks etc) but suffice to say me and my friend had fun making them and definitely want to continue making them.
These are starting off at the lowest-entry point, intermediate and advanced mappers need not apply, literally the first vid is about installing quake, getting wads, downloading software etc and then working up to "my first room". 

Looking forward to seeing them! 

I'm in't Penrith. 

I'm not as north as you are, I'll give you one clue though...

"garlic bread is the future, I've tasted it!" 

Garlic....... BREAD?!?! 

Yep... My next map is a caravan for me mam. 

Can you try running TB from code blocks in the debugger? Strangely, it works for me that way on my VM.