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. 

I have no idea how to do that, I'm not familiar with Codeblocks at all (nor with other IDEs, I use vim). 

 

Please update the sources and recompile, then run the editor (not from the IDE). It may fail on the first try, but it should work the second time. I have no idea why this is happening, but at least it now works on my VM and my MacBook Pro in Ubuntu 12.04. 

I did that. After that suggestion, I got it running on the third try. I experimented with this some more, and it seems to be random if it runs or crashes. But when I try enough times, I can get it to run.

It seems to crash when I press "V". This can be reproduced; this is the message:

(TrenchBroom:16513): Gtk-CRITICAL **: IA__gtk_window_resize: assertion `width > 0' failed
TrenchBroom: /home/jonas/TrenchBroom/Source/Renderer/Shader/ShaderProgram.cpp:155: bool TrenchBroom::Renderer::ShaderProgram::setUniformVariable(const String&, const TrenchBroom::Math::Vec3f&): Assertion `checkActive()' failed.
Afbrudt (SIGABRT)

Under "View -> Grid" I can select all grid sizes with the mouse at the same time (so they are all shown as toggled on with a hook in front).

When I click on "Snap to Grid", the 1 unit grid is displayed no matter what grid size I have selected.

Is there a key combo to snap a brush to the currently selected grid size? Shift-Ctrl-G doesn't do it and I can find nothing else in the Preferences.

Movement with WASD is jerky, there is a delay between button press and reaction and sometimes a stuttering effect to it. Rotating the camera stutters also. It won't accept multiple button inputs (eg W and A) at the same time (does nothing in such a case). I've tried all the different OpenGL Instancing settings.

Those are my initial findings, I'll give it some more time. 

I managed to enter vertex mode once, so that bug actually doesn't *always* happen. 

The vertex mode crash is usually fixed by setting the Instancing mode to "Force off" in the preferences. If that doesn't work for you, I'll have to investigate some more. Could you paste the stack trace for the crash at pastebin or something? The lines get truncated.

Movement is not implemented like in game ATM - there is no "fly through" mode yet. Pressing "A" actually just invokes the menu item for "Move Camera Forward", that's why you can't press multiple keys at once.

There is no command to snap a brush to grid size, "Snap to grid" toggles grid snapping. Rotation should be smooth - are you running a release or a debug build? 

Awesome, setting instancing to "force off" seems to prevent the crash indeed. So far, so good.

I was running a debug build. I'll try a release build.

I intend to also try this under Windows, so that I can form an opinion with the various bugs out of the picture.

I see about the movement.

At least I see an editor now, thanks for bearing with me. 

Sorry I didn't notice that.

http://pastebin.com/4878suLa