[Gtkradiant] Issues with Zeroradiant...

Rich rich at hq.vsaa.lv
Tue Apr 8 06:49:51 CDT 2008

first, sorry for possibly breaking the threading - i tried to preserve 
it at least for some :)

i've been using gtkradiant for some ufoai stuff recently, and was told 
that zeroradiant branch is the future, so i tried it.
mattn already sent some of the issues i faced to this list, i'm adding 
some new ones.

note that i'm not informed about political, technical and other aspects 
regarding gtkradiant/zeroradiant, i am simply speaking as a person who 
has used gtkradiant, then tried to use zeroradiant.
this is self compiled zeroradiant svn head (on slackware-current).
i'll try to note which issues were not observed in gtkradiant trunk, in 
case that helps any.

i would be glad to test new versions, patches and whatnot, also i could 
report issues on the tracker, if there would be anybody interested to 
work on them :)

issues from the original thread :

 >>  1. file chooser does not remember last directory used and does not
 >> default to ufoai map direcoty as trunk did

 > That's annoyed many people for a long time.

 >>  2. ugly grid numbers (for example, 64 - 4 is very small, 128 etc)

see http://tndruka.lv/stuff/ind/zeroradiant/01_characters.png
also names like func_group etc look like that.
is ok in gtkrad.

 >>  3. very low grid doesn't show smallest reasonable, it jumps to a large
 >> grid (for example, zoom out, select grid 1 - looks like grid 7 or so)

is ok in gtkrad.

 >>  4. mousewheel does not work on mouseover, i have to click in the
 > desired view (x/y/z) before

 > Note this may be platform dependent (Windows in particular). 
Definitely need to get the mouse wheel working on mouseover on all 
platforms.  May involve some GTK2 quirk.

 >>  5. grids smaller than 1 don't have grey/black gridlines as a difference
 >> for larger gridlines (as trunk had)

actually, also other grid sizes have this problem, but gridsizes smaller 
than 1 are worse.
for example, in gtkradiant : 

notice how larger grid lines are thicker. this follows zoom, with every 
zoom being chosen a reasonable "parent" thicker line zoom

first, the choice of "parent" grid is not as smart in zeroradiant, and 
doesn't work in all cases (maybe effect of 4. ?)
second, zoom levels smaller than 1 show all lines completely black (they 
are grey and have correct "parent" identification in trunk).

 >>  6. there are no two smallest grids possible as in trunk - probably not
 >> a problem as such, only could cause problems with existing maps

 > The fractional grid sizes?  I think zeroradiant may lack floating 
point map coordinate support, so this would be a deeper issue.

zeroradiant has 0.5 and 0.25, trunk additionally has 0.25 and 0.125.

 >  7. there are no buttons in ui for selection of edges/corners/faces, and
 > i couldn't even find out how to select a face at all

 > All hail modifier keys.

 > See the manual?

hmm. well, if by modifyer keys you mean shortcuts, i tried pressing 'f', 
like i did in gtkradiant trunk. that did not work. then i looked all 
over interface, trying to find the three buttons i had in trunk version 
- selection of edges, vertices, faces. i'm just probably too stupid, but 
i couldn't find them :)

trunk has menu items modify->components->f/v/e, while zerorad has 
selection->drag v/e (missing f mode) - could this be connected ?

 >>  8. when selecting corners (vertices ?), i very often get some blue dot
 >> that i can drag around, but actual brush doesn't change at all...
 >>  last one is the weirdest
 >>  that's the issues i spotted in first minutes using it ;)

 > Blue dots (you might see up to 3 of them) are clipping plane control 
points for chopping brushes, they are not directly attached to any brush 
and aren't what you're looking for (although they are very
useful for making sloped cuts on multiple brushes simultaneously).

 > Again, you're doing it wrong :)

hmm, most likely. i couldn't spot that problem as often yesterday, so i 
guess i had some weird mode selected or something :)

 >> The file chooser annoys me, too - but i'm not sure how to handle these
 >> things. Should i send patches (because these changes will of course not
 >> only change q2 related stuff)
 >> Martin

 > I think we want all of these issues fixed - except for 7/8 (adding 
multiple selection modes might unduly complicate the editor codebase).

e/v keys work for selecting edges/vertices, f key does not work. so it 
seems two of the modes are there (though they lack ui buttons, which 
helped me a lot, especially when i just started with gtkradiant).


now, i'm adding some more problems. obviously, it would be much easier 
to handle in a tracker, so again, i'd be happy to file ones that are 
considered reasonable.

2. http://tndruka.lv/stuff/ind/zeroradiant/02_tooltip.png on 1024x768, 
tooltip is partially pushed out of the screen

5. position the cursor in the middle of the 3d view, right click that 
view. try to move out of that mode reasonably

6. select a brush. deselect it, select another.
enable view->show->show workzone. notice how workzone shows previous brush.
deselect that brush. notice how now workzone shows previously selected 
brush (it should disappear instantly). (this part worked fine in gtkrad)
select and deselect new brushes. notice how workzone does not change.

12. in trunk, selecting f/v/e mode, then one of the brush parts did the 
following : first pressing of esc deselected currently selected 
faces/edges/vertices, second quit the subselection mode (leaving only 
the brushes selected), last esc keypress deselected the brushes. in 
zeroradiant, esc immediately delselects everything after the first 
keypress. trunk behaviour was more desirable.

13. e/edge mode in trunk had unselected handles green, selected - blue. 
in zeroradiant, all handles are blue, there is no indication of selection.

14. dragging vertices in zeroradiant can break faces in triangles. can 
this optionally be disabled to introduce trunk-like behaviour when all 
faces are kept flat in all situations ? note, both modes are useful, 
it's the switching between them both that seems to be missing.

15. help->manual - "sh: 
No such file or directory" :)

16. trunk has an ability to filter for "map" files in open dialog. that 
would be useful in zeroradiant as well

17. starting positions entity direction arrows
http://tndruka.lv/stuff/ind/zeroradiant/05_arrows_trunk.png - entity 
arrows in trunk;
http://tndruka.lv/stuff/ind/zeroradiant/06_arrows_zero.png - entity 
arrows in zeroradiant.
notice how trunk arrows look better (and they are coloured according to 
entity in question).
they could be thicker, though.

18. brush edges for the selected brush that are behind other brushes or 
faces of the same brushes
http://tndruka.lv/stuff/ind/zeroradiant/07_brushes_behind_trunk.png - in 
trunk, those edges are not continuous, thus making them much easier to 
http://tndruka.lv/stuff/ind/zeroradiant/08_brushes_behind_zero.png - in 
zerordiant, they are continuous, thus making it very hard to understand 
what is what

here come two backtraces. all i need to know is where the problem is 
located - if it is not in radiant, i'll file them with the correct 
project (gtk ?)

19. opening africa.map from ufoai :

Program received signal SIGSEGV, Segmentation fault.
0xb731b495 in _int_malloc () from /lib/libc.so.6
(gdb) bt
#0  0xb731b495 in _int_malloc () from /lib/libc.so.6
#1  0xb731cb2d in malloc () from /lib/libc.so.6
#2  0xb78145c6 in g_malloc () from /usr/lib/libglib-2.0.so.0
#3  0xb650b19e in LoadJPGBuff () from 
#4  0xb650b47f in LoadJPG () from 
#5  0x080c722b in CRadiantImageManager::LoadImage ()
#6  0x080c7360 in QERApp_LoadImage ()
#7  0xb6328cdb in QERApp_Try_Texture_ForName () from 
#8  0xb6329f94 in CShader::Activate () from 
#9  0xb632a23b in QERApp_CreateShader_ForTextureName () from 
#10 0xb64be535 in CPicoSurface::CPicoSurface () from 
#11 0xb64bd53c in CPicoModel::load () from 
#12 0xb64bda2b in CPicoModel::CPicoModel () from 
#13 0xb64c01a6 in LoadModel () from 
#14 0x080c9be0 in CModelManager::GetByID ()
#15 0xb651ded6 in CEntityMiscModel::SetName () from 
#16 0xb651b312 in Entity_OnKeyValueChanged () from 
#17 0xb63855ce in Entity_Parse () from 
#18 0xb63856eb in Map_Read () from 
#19 0x080bea77 in Map_Import ()
#20 0x080bf50e in Map_LoadFile ()
#21 0x080aa24e in MainFrame::OnFileOpen ()
#22 0x080b5c72 in HandleCommand ()
#23 0xb78ba0df in g_cclosure_marshal_VOID__VOID () from 
#24 0xb78acd99 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#25 0xb78c157b in ?? () from /usr/lib/libgobject-2.0.so.0
#26 0x08240668 in ?? ()
#27 0x00000000 in ?? ()

20. entering a directory name in open dialog, pressing enter :

Program received signal SIGSEGV, Segmentation fault.
0x080c3d35 in CSynapseClientRadiant::ImportMap ()
Current language:  auto; currently asm
(gdb) bt
#0  0x080c3d35 in CSynapseClientRadiant::ImportMap ()
#1  0x080bea77 in Map_Import ()
#2  0x080bf50e in Map_LoadFile ()
#3  0x080aa24e in MainFrame::OnFileOpen ()
#4  0x080b5c72 in HandleCommand ()
#5  0xb78c10df in g_cclosure_marshal_VOID__VOID () from 
#6  0xb78b3d99 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#7  0xb78c857b in ?? () from /usr/lib/libgobject-2.0.so.0
#8  0x081e5c20 in ?? ()
#9  0x00000000 in ?? ()

21. http://tndruka.lv/stuff/ind/zeroradiant/09_size_location.png - trunk 
shows size and location of the selection (notice the x/y stuff that is 
shown both for single selected brushes and for multiple selection) - 
would be nice to have in zeroradiant.

22. in trunk, ctrl+alt+e completes func_group selection of selected 
brushes. in zeroradiant, this does not work.


on the plus side, zeroradiant at least seems to be somewhat faster than 
gtkradiant trunk, so i would be glad to test and use it.

More information about the Gtkradiant mailing list