The warnings are fixed now. I'll look into the directory issues. 

For anyone who is trying to use TrenchBroom in Linux Mint, I also found out how to disable alt+drag moves window (using Mate... not sure about Cinnamon):

At the terminal, run mateconf-editor
In the configuration Editor window that appears, enter apps->marco-general and change the setting for mouse-button-modifier to "<Super>" to use the super key (probably the windows key) or "none" to disable it altogether. The default is <Alt>, but this is fucking stupid, since lots of applications use alt. 

Regarding the garbled text, could you please scroll the console all the way up and paste the first ten lines where it says whether OpenGL instancing is enabled or not? 

enderer info: Mesa DRI Intel(R) 965GM x86/MMX/SSE2 version 2.1 Mesa 9.0.2 from Intel Open Source Technology Center
Depth buffer bits: 0 < WTF!?
Multisampling disabled
OpenGL instancing disabled

I set it to be forced off because otherwise vertex mode crashes the editor.

Also, I didn't notice until I tried loading some more complex maps, but the 3d view is extremely buggy. I'm getting missing surfaces all over the place, and I think some option I tweaked made all the normal flipped or something weird like that. The depth buffer or render order also seems to be borked. It's a mess on my laptop at least. I want to try it on my Ubuntu machine that has a sensible nvidia card and see if I experience problems there. I notice you have a screenshot on the TrenchBroom site taken in Linux that looks perfectly fine, so I'm guessing it might be an issue with my lame graphics chip.

Oh, a couple of other things:
1. If I click on the window title before trying to use a menu for the first time, the menu appears briefly, then disappears and none of the menus are useable. Could it be a wx or GTK problem?
2. When I quit TrenchBroom, sometimes I get an assert fail "../src/common/glcmn.cpp(60): assert "IsShownOnScreen()" failed in SetCurrent(): can't make hidden GL canvas current"
ASSERT INFO:
../src/common/glcmn.cpp(60): assert "IsShownOnScreen()" failed in SetCurrent(): can't make hidden GL canvas current

BACKTRACE:
[1] g_cclosure_marshal_VOID__VOID
[2] g_closure_invoke
[3] g_signal_emit_valist
[4] g_signal_emit
[5] gtk_widget_map
[6] gtk_container_forall
[7] g_cclosure_marshal_VOID__VOIDv
[8] g_signal_emit_valist
[9] g_signal_emit
[10] gtk_widget_map
[11] gtk_container_forall
[12] g_cclosure_marshal_VOID__VOIDv
[13] g_signal_emit_valist
[14] g_signal_emit
[15] gtk_widget_map
[16] gtk_widget_set_child_visible
[17] g_closure_invoke
[18] g_signal_emit_valist
[19] g_signal_emit
[20] g_cclosure_marshal_VOID__OBJECTv
[21] g_signal_emit_valist
[22] g_signal_emit
[23] gtk_container_remove
[24] g_main_context_dispatch
[25] g_main_loop_run
[26] gtk_main

No idea what's going on there.

This is the graphics chip I seem to have:
VGA compatible controller : Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) (prog-if 00 [VGA controller])
Display controller : Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) 

http://andyp123.blogspot.jp/2013/03/running-trenchbroom-quake-editor-on.html

There are possibly some things I missed, and it's basically just an expanded version of Linux/Build.txt, but maybe it's of use to someone. If there are any problems with it, please let me know so that I can fix it. 

You must use the master branch for the Linux version, it has a lot of fixes. The 1.0.5 branch is pretty much broken on Linux. 

ok, so there is no depth buffer it seems. The wireframe of all brushes is always visible - even when there are other brushes obscuring it, unlike in the windows version, and if I do a simple test with three brushes, it's obvious there is no depth culling. This is probably down to my shitty video card, the drivers or some combination of the two, and I don't expect you to fix it since TrenchBroom is just a personal project and fixing shit like that for one guy running on a Linux notebook from 2007/2008 is not of the upmost importance. Still, if you have any idea what the cause might be, it would be good to know. 

ok, I'll try that and see if it works. 

That's odd, but it could very well be a bug in how I am detecting the available pixel formats on Linux. I'll look into this, so keep that laptop around ;-) 

I am pulling direct from the master now and there are no differences with regard to bugginess on my machine.

I'm kind of done with this for today, but tomorrow or perhaps Tuesday I'll try and get it running on my Ubuntu machine and also use my experience from today to get it building with Code:: Blocks on Windows (I hope).

Ideally I'd love to have it running flawlessly on Linux, but I'll be happy to get the Windows version building so I can try adding new features. 

The menu issues are still there on the master branch? 

At least on Linux Mint Mate. Not sure if it's just an issue related to my specific setup.

Load TrenchBroom
Click on any menu (the file menu for instance)

The menu should appear then quickly disappear. The entire GUI is completely unresponsive after that and I have to kill the process to get rid of it :/ 

I fixed the errors with the hexen2.def file I had.

Fixed hexen2.def
Download: https://docs.google.com/file/d/0B0piElswxauhbnZJQ2Q2WGxHUDg/edit

Errors/fixes were:
1) Removed first 5 lines(a custom comment).
2) Search & Replace all " / " with "/"
3) Search & Replace all lines that tail: ") ?", and replace that tail with ")"

These fixes were based off the error messages I received in the console log of TrenchBroom. Thanks to the log messages, I was able to fix these manually myself.

It loads fine, and I get hexen2 entities now.

Models:
However, it's not loading the models. I tried renaming my hexen2 /data1/ folder to /id1/, because it has same pak files, and the pak files have same file structure. But, I couldn't get this to work.

Textures:
I could not get it working. TrenchBroom won't load the hexen2tx.wad file I downloaded from:
http://www.realm667.com/index.php/texture-stock-mainmenu-152/1090-hexen-ii-texture-pack?catid=56%3Aheretic--hexen-style

---

Perhaps these issues are side-effects from the fact that the hexen2 is a custom quake1 engine. 

Alright, I'm done with TrenchBroom for now.

I can't use it effectively unless I have grid information. Bit I have no grid information--all the opengl text is garbled--and I have no grid view or grid anything to look at for measurements.

I understand the editor is to be seamless flow for a mapper, but I prefer to be accurate and I always work with grid information and grid numbers, and a flat grid view.

Thanks, 

Hello deqer,

I suspect that it's not loading the models since they have a customized MDL format for Hexen 2. For each games meshes to show up Trenchbroom would need to have a custom loader for the various MDL, MD2, MD3 and so on.

Cheers 

Really nice! It's like Blender but with brushes...hmmm...hopefully there will be ample hotkey customization.

This looks and feels incredible! Fluid views, oldstyle graphics(not gl blurred! :) ), Brush splitting!! Amazing. Simply amazing.

However, I have noticed one minor issue. Texture application takes a while...about 2-3 to do any change to the texture. I have Nvidia driver 306.97, though I haven't noticed any issues with it, though perhaps it has something to do with having multiple monitors. It does slow down my texturing process a lot.

Anyways its great so far! Keep it up! 

Grid snap does't snap to the global grid! It's local. Instead of moving a face to the next gridline it just moves it the current grid distance. For example, if a face whose global X-value is 32 is moved 2 units to 30, then when switching back to any other grid size like, say, 16 then the X-value would go from 30 to 14, not 30 to 16 which is how other editors work. Is there a setting for this? 

I disabled and then reenabled one of my monitors and it fixed the slow texturing problem. Wierd. Just FYI. 

grid snapping to offsets is intentional. Force a vertex to snap to grid by holding shift while you move a vertex.
Not forcing the snap lets you do more such as work at large grid sizes without loosing small details. 

It is a spectacular editor though. The best feature is the texture rendering in 3d view, and texture management in general. I also like the grid lines on the brushes, and the extending helper grid lines when selecting a brush.

I will use 3d view a lot. But, I also use flat grid view just as much. Please provide grid view or something equivalent. 

Hello SleepwalkR,

Do you think its possible to add a world center and limits info to the 3d viewport? It would be most helpful in figuring out the center and maximum boundaries of the level. Some form of coordinate system that has a 3d grid which fades out after a set distance which can be turned on and off? That way folks that like a grid or none at all will live happy ever after. For me its good to get my bearings.

Otherwise loving this. 

add the name of the level and things in TrenchBroom? 

it took me until now recognise the origin of your nick, I should read more!

add a "name" field to the worldspawn. 

Showing where the center is and where the world ends has been requested by others. I'm still thinking about how to do it without cluttering the view port. Maybe it can be combined with a way to give people more orientation and a better idea of the relative position of objects. 

Compiled on my main pc running Ubuntu 12.10. Had some minor troubles during compilation, but fixed and it runs just fine as far as I can tell (not tested extensively yet, however).

Everything is working fine, but wxWidgets setup.h seems to redefine SIZEOF_LONG as 8, where it has already been defined in freetype. Commented out the highlighted line and it compiled without issues.

The z-buffer is working fine:
Renderer info: GeForce GTX 560 Ti/PCIe/SSE2 version 4.2.0 NVIDIA 304.51 from NVIDIA Corporation
Depth buffer bits: 24
Multisampling disabled
OpenGL instancing enabled