Itches, Glitches & Anything Else...

[Fidcal]

Brushes generally disappear if you drag them to zero. I've always thought it might be good if the minimum dimension were made 0.25 (or is that 0.125?) so this doesn't happen. Perhaps this might solve this new problem?

[greebo]

Greebo, I have encountered a serious crash (assertion failure) if you create a brush and then drag it so that it would become infinitely thin. The stack-trace is:

 

I could investigate if needed but I don't know anything about this code -- is this related to any of your recent changes?

Yes, this is most likely related to the Array-to-std::vector conversion I was doing lately. Don't worry about that, I'll look into it.

[OrbWeaver]

I saw your committed fix, but haven't had a chance to test it yet. If this is fixed we should probably make a 0.10.1 bugfix release, since this is a hard crash which is rather easy to trigger.

[greebo]

The crash only appears in debug builds, though. In the actual release build I could resize the brush down to zero size without a problem, but still the size info drawing in the orthoview went wrong.

[OrbWeaver]

OK, that's not so serious then.

[SneaksieDave]

If a snapshot is made anytime soon, could someone tell me in advance what change was made (or how to find it) regarding the splitpane resizing? I'm considering trying to address it myself if no one else is willing. I don't know if I'm up to it but I'd try, as I consider it fairly important for reasons already indicated. Wish I could build DR myself but I think that's a pipe-dream since I don't have the req'd software (I think?).

[Fidcal]

Temporarily you might try floating. I have mine set up with half camera/half grid much like you but floating. You won't be able to drag the middle bar left and right in one operation but it will look similar and you can double click the top bar for full screen.

[SneaksieDave]

Oh I can work around it, it's just itching me badly (hence the name of this thread ). I feel like if something can be done, I should give it a shot instead of just waiting possibly a long time.

 

Edit: ooh wait. I just looked at the DR compilation guide. The software which can compile it is available in a free edition....?

[greebo]

Edit: ooh wait. I just looked at the DR compilation guide. The software which can compile it is available in a free edition....?

Yes, VC++ 2008 Express Edition is free.

[SneaksieDave]

Well I guess the change wasn't too hard to find,

 

const int XYWND_MINSIZE_X = 100;

const int XYWND_MINSIZE_Y = 100;

==>

const int XYWND_MINSIZE_X = 0;

const int XYWND_MINSIZE_Y = 0;

 

in XYWnd.h, with similar treatment of the CAMWND_MINSIZE_X and CAMWND_MINSIZE_Y consts in CamWnd.h:

 

const int CAMWND_MINSIZE_X = 240;

const int CAMWND_MINSIZE_Y = 200;

==>

const int CAMWND_MINSIZE_X = 0;

const int CAMWND_MINSIZE_Y = 0;

 

Couple problems:

1. I don't know the reason for the change in the first place, so perhaps a value of 1 would be more stable than 0, or maybe both will cause problems. So far, in just dragging the bars around, it doesn't seem any more or less stable than before the change.*

 

2. Question: for some reason I can't drop the new exe (release) into my 0.10 folder and go, because loading any saved map crashes DR before the load finishes. Is this because other changes have taken place since then, so I need all of the support files as well? If so, is there an automated install build script or something so I don't have to try making a Franken-Install by hand?

 

* All of that said, it seems terribly unstable since the original change (0.10 release, before mine) anyway, as reported in that crash bug on the tracker. I can get it to reliably crash by just dragging the divider bars up and down repeatedly. If a new drop does come soon to address the crashes, please consider including the 0 or 1 minsize changes above.

[greebo]

2. Question: for some reason I can't drop the new exe (release) into my 0.10 folder and go, because loading any saved map crashes DR before the load finishes. Is this because other changes have taken place since then, so I need all of the support files as well? If so, is there an automated install build script or something so I don't have to try making a Franken-Install by hand?

When VC++ is done with compiling, you'll find a full, ready-to-go installation in your install/ folder. There is the exe and there are all the modules and plugins. You can start DR right from that location.

[greebo]

@SneaksieDave: rev 4654 contains a fix for your issue.

[SneaksieDave]

Cool thanks, I'll check it out! Especially now that I can sync and compile

[SneaksieDave]

Looking good, issue closed. The code is over my head. I can confirm I do still get the crashes when aggressively flicking the panes around, but it works better (every pixel shown) than my 'fix' of just hardcoding a size limit.

 

On a side note (and not wanting to derail): what is ctrl-shift-b (for build) as opposed to the other options in the Build menu? I assume Build solution is the whole project and Rebuild solution is probably to clean first and rebuild everything explicitly. But I don't see ctrl-shift-b in the menu anywhere, and it was faster and had fewer steps, so I'm wondering if it should be used with care (and only when you know what you're doing), that I might compile stale code?

[greebo]

Build Solution does no more than what is absolutely necessary. It automatically detects which files have been changed, and which other files are depending on them. In the ideal case, only one single file has to be recompiled before the package can be assembled/linked, in the extreme case (e.g. if one of the math headers is changed) you need to recompile almost everything.

 

Rebuild Solution is just a shortcut for (Clean Solution + Build Solution). Clean Solution makes the project discard all previously compiled stuff and starts from scratch. This takes up to 15 minutes here on my end, and I avoid that whenever I can.

 

Short story: you can safely use Build Solution whenever you get incoming changes, unless you change the build configuration (Release/Debug/Win32/Win64).

[Crispy]

Unless weird shit is going down (odd linker errors, code changes seemingly not applying, etc.), in which case sometimes a clean build can help clear away problematic cobwebs. But that's rarely needed.

[SneaksieDave]

I've been noticing something strange recently. It seems the preference setting:

 

Orthoview | Update Views on Camera Movement

 

is only partially working anymore. I have it off for optimization, but it still sometimes (perhaps 2/5 of frames?) updates the ortho view anyway. If I turn it on, I get the expected result; as I move around in cam view, the ortho view cam icon is fully updated with every move. But then turn it back off, and now it still sometimes updates the view, even though it's not supposed to at all. Best way to see this is to go into cam mouselook and use the arrow keys to fly around a map.

 

Edit: it seems to be worst when the view is complex (e.g. big map, all or many entities showing, whole map in ortho etc -- just tax it). FTR this is on my fastest work machine (core 2 duo 2.66GHz).

[greebo]

The orthoview updates can be triggered by many events. Some are issued by the code (forced update), some are requested by the OS/Window Manager itself. For instance, if you switch back from another application or resize DarkRadiant's windows - a so-called "expose" event is fired and this triggers an update.

 

So, in short words, I wouldn't expect that - with that setting off - the orthoview will never be updated.

[SneaksieDave]

This is weird. Based on what you said, I had an idea that maybe it was unique to the splitpane and embedded views, and wouldn't happen on floating. So I switched. Seemed the guess was on the right track, because the same behavior was not showing with floating. However, it didn't happen with embedded either. So I figured, great, it's a bug in splitpane :-/. However, when I then switched back to splitpane, it wasn't doing it anymore. I restarted to repro the experiment, but this time, switching modes did not help. So something in the first trial alleviated the demand (I don't think it was about caching because this system is running only DR in 2Gb memory and it's fassst to load) and I'm not sure what. Will play with it more and report if I can find any consistency. It's possible it's just a matter of having a crap video card, and I never really noticed it on my game system, which has a geforce.

[Fidcal]

A small suggestion: after a big map has loaded there is a long wait while presumably the code is processing the data it's loaded. The Loading Map dialog is not cleared (more likely the camera and grid view are not redrawn) so it looks like the program has crashed for maybe a full minute. I suggest replace or add to that dialog a message: 'processing...' or similar? (note this screenshot shows whited out areas but this was only after grabbing the screenshot - normallythe camera and grid view show normally with the dialog broken across them as though the background has redrawn but not camera or grid. If they were redrawn then it would still look like a crash for a minute if there is no message.

 

[SneaksieDave]

See/report this kind of stuff with our software for work (which does video) regularly. A forced redraw of the UI and/or the dialog should take care of it.

[OrbWeaver]

A forced redraw of the UI and/or the dialog should take care of it.

 

Adding the calls to update the UI is the easy part; identifying the code which is actually causing the delay (and into which the redraw calls need to be inserted) is the challenge. I remember doing some profiling of map loading a long time ago; although certain aspects were improved, there are still areas that need to be identified as you can see.

[Tels]

Adding the calls to update the UI is the easy part; identifying the code which is actually causing the delay (and into which the redraw calls need to be inserted) is the challenge. I remember doing some profiling of map loading a long time ago; although certain aspects were improved, there are still areas that need to be identified as you can see.

 

There is also the question what good does it the user do it the screen is refreshed, but he can't use the editor while the load is still progressing, but has no indication that he can't (so it looks like a crash or hang).

[greebo]

During the first redraw all shaders are realised, i.e. loaded from disk. That (I assume) is what is causing the lag.

[Fidcal]

Which events change or empty the shader clipboard? I'm finding that when doing extensive decal griming that I suddenly find its pasting shader not found for no reason. I'd prefer to lock the shader clipboard. I can't be accidentally filling it because I'd have to select a shader not found surface first.

 

Also, is there any way to add a decal shader to the shader clipboard apart from creating a special brush and giving it a decal surface? I don't think it works from a patch. eg, right click shader in texture browser and select 'add to shader clipboard'