radon

Just fired up TDM on new system after a pause, built dark radiant via ebuild from wiki install instructions and encountered this bug. Small texture preview in "media" tab is not updating, and so is "textures" tab. Texture selector in Surface inspector works fine however. Textures tab updates and show textures when typing into filter field. I also get a lot of spam in terminal, in shape of "(darkradiant:10678): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton", but that may be unrelated. I upgraded wxGTK to latest (3.0.4) and then checked out and built last tagged version (2.6.0) of radiant, to no avail. Any ideas?

Now this is interesting. When run from darkmod directory via ./thedarkmod.x86 , it fails as noted above. However, if I make chdir to /opt/doom3 first and run darkmod from absolute path, it works well. There is something fishy with the new launcher.

I just got bitten by this too and I'm pretty sure my doom3 install is ok. Package README lists md5 of game paks and they match. Doom is playable. Reinstall of game binaries or tdm wont help.

No, my point is that Colors dialog itself is not exactly "exposed". In fact, it took me a while to find it. While testing various grid styles, I noticed that color play as big part of the game as the grid style itself (surprise :-) and I had to change it quite often with changing grid style. The two are linked, yet navigating to different modal panel in another menu branch is not exactly handy. I'm not thinking of moving those color choosers completely, just some kind of shortcut. That's exactly why I made no move there yet - and why I ask. "Spending time" is not an issue, creating integer option turned to be easy once I get hang of it. Creating incomprehensible clutter is not any harder, I know that much. OTOH I may not chosen best magic numbers. For all I know, they may even be hardware dependent. They sure are taste dependent. I like it the way it is, but If somebody wants to play around, it can be done. Shifting along axes would still respect grid, only smaller/denser then visible one. Rotating is just a wild idea, I sure as hell am not able to code it. I can't believe any graphic card capable of running tech4 may have performance issues with what is basicaly blitting few copies of 2D sprite. Damn, even tech1 age hardware could do that without much sweat. DCK editor sure did it. Yeah it's kind of silly, but I like to excercise my rusty C++ skills and with zero knowledge of 3D, there is probably not much else I can help with. Think of it this way - its the tiny part of UI, but one you spend a lot of time looking at. Feeling comfortable can't hurt here.

Well, all I wanted is pretty much done. So my biggest question right now is - what else should be done with that particular piece of code, while I'm having my hands on it? Few things that pop to my mind: Add color selector to grid configuration dialog. "Lines" grid (which is default) needs light, nondistracting color, easily distinguishable from polys. All other grid methods do better with more contrasting colors, having proper color selector right there would be handy.Magic numbers can be made configurable. Size of dots, density of dotted lines etc. I'd call that overkill, may somebody find it useful?Ability to shift grid around. One may need to design larger piece of map at (mostly) certain size (to have textures aligned) but not exactly at default grid points.Drop the current grid rendering entirely and use user-selected bitmap instead. Customizing grid would then be matter of drawing a cross in bitmap editor.Ability to rotate grid or canvas. As of now, creating anything not aligned to major axis is either pre-made model or pain in the ass.

Feel free to take over. I said upfront I don't know a thing about this stuff. Just happened to stumble upon DR source while being annoyed by visual clutter and longing for QuArK.

Thanks a lot, that's exactly what I was looking for. Expect improved patch soon.

If you want to give it a try, patch is in bugzilla (0002574). I've played a little bit more with the code and made minor and major grid settings independent of each other. Any other ideas?

I will post patch to the bugtracker as soon as I manage to make it configurable. So far, I'm very good at making segfaults :-( If you don't mind compiling your own radiant, I can throw in a patch.

Trust me, I've tried. Actually, major grid is full black and minor is halfway grey, but it doesn't get any better even with major full red. There is no space for color information that my eyes could sense. It gets a little better on CRT monitor, but hey, who has one of those nowadays…

Here we go. On plus side, minor grid is a lot better visible. On minus side, I can not see major grid at all.

Exactly. It worked great in good ol' QuArK days of lower resolution, but today pixels are just too damn small. I was thinking about little crosses (barely visible, think of bigger dots) to give stronger visible cue yet avoiding cluttering lines. But whole thing is rendered and scaled via oGL, without way to address screen pixels. I have no idea how this 3D stuff is supposed to work, but apparently it's not addressable in a linear way. Small lines get distorted - see the screenshot. If any present 3D guru can point me in right direction, I'd be glad. Otherwise, your "dotted lines" idea does not involve munching through GL specs, so it's my next shoot :-)

That was the idea. Dots were easy, but I can't grok the preferences system. Positive feedback sure helps me concentrate :-) I'm afraid not, I don't know first thing about 3D geometry, OpenGL or even GTK. I've just kicked some existing code to different shape.

I've hacked one tiny feature I'm missing in darkradiant - grid lines made of dots. See "before" and "after" screenshots to get an idea. Anyone interested in pushing it upstream?