New Colour Scheme Handling

[greebo]

Actually, there was just the according update call missing - the colours were reloaded correctly, but the scene was not updated after reloading. This is fixed now as well as a bug with reflecting the read-only status when only one scheme (the default scheme) is left to edit. I also changed the copy behaviour, the newly copied schemes is now automatically highlighted.

[OrbWeaver]

Seems good.

[greebo]

Ok, I've replaced some more hardcoded colours, including the colours of...

 

...the small x,y,z axis indicator

...the workzone lines

...the camera icon

...the brush size info

...and the light volumes.

 

At the moment the "selected brush" feature requires a DarkRadiant restart for the changes to take effect, I couldn't find out where this colour is set, perhaps I stumble on it in the future.

 

I had to implemented an override of the light volume colour (which is originally defined in misc.def), so that one is able to choose the colour via the scheme editor.

 

Additionally, the function colourschemes() is now available in GlobalRadiant(), although it's unused at the moment.

[OrbWeaver]

That's what I like to hear. I want my ugly magenta light volumes, not barely-visible green.

[greebo]

I'm still looking for the red overlay of selected brushes in the camera window, but instead I found the colours for patch and brush vertices. These are on SVN now. I also had to increase the row count in the scheme editor, since it was getting really big.

 

BTW: I recently built DR in release mode for angua, and now scons defaults to release mode when hitting Ctrl-B in Eclipse (this is kept till I clean the targets or force scons to build in debug mode). When compiling in release mode my build times have decreased dramatically (5 sec. for the exe link), as you have experienced it before, so maybe the build mode is the reason for the ultra fast linking.

[OrbWeaver]

That is interesting, and counterintuitive. I assumed release builds would take longer to build because of the optimisation, but maybe the extra debug information makes the link take longer.

 

If this is the case I might as well use Release mode all the time in Windows, since my GDB long stopped working on the platform (and I would do all major debugging in Linux anyway).

[greebo]

Well, the debug exe is huge IMO (takes 60-70 MB), the release build takes only 4.2 MB of disk space, so there is a LOT of code or information missing in the release build. But as I use globalOutputStream() for debugging anyway, the missing debug info doesn't affect me. I really hope that this effect lasts, as I'm working at least 60% of my time on Windows.

[New Horizon]

Ahhh, that explains why my builds have been taking so long under linux then. Can I force scons to build a release in the commandline?

[OrbWeaver]

This seems to be a Windows-specific problem, on Linux I get the same short link time for either build.

 

You can trigger a release build by typing "scons BUILD=Release"

[New Horizon]

You can trigger a release build by typing "scons BUILD=Release"

 

Hmmm, that command doesn't seem to work for me. I'll try again later, I'm just on my way out.

[greebo]

Try this:

scons BUILD="release"

[sparhawk]

The size of a debug build is of course because all the extra info is stored. But depsite the size, the build should be much faster then a release build, because in a release build you usually have optimiziations switched on, which take a much longer time then just the disc access.

[SneaksieDave]

I'm still looking for the red overlay of selected brushes in the camera window

Are you referring to the red highlight, or the dotted red border in the isometric views? The latter, I must say, has forever been my most petty, pet-peevish bother. I hate that red dotted selection!

 

(not as much as I used to though )

[greebo]

No, the colour of the dashed brush/patch selection lines is already customisable, I referred to the camera view (render view), where all objects are being half-transparently overdrawn with a red colour when selected.

 

BTW, you can change the dashed line to a solid line via the preferences, so the selection highlighting is fully adjustable at the moment.

[SneaksieDave]

Nice! I hadn't seen that, thanks.

[OrbWeaver]

I have done some minor refactoring of the ColourScheme code

 

- ColourItem is a child class of Vector3, rather than a wrapper. This means that all functions defined on Vector3 are automatically available on ColourItem, and do not need wrappers. It also means you can pass a ColourItem directly to a glColor3fv, since a Vector3 is automatically cast to a float* in this situation.

- ColourItem's constructor from an XML node passes the string value to the Vector3 constructor, rather than parsing itself with string_parse_vector3 (a deprecated GTKRadiant function).

- Removed ColourScheme::colourExists() which was only called by the getColour function, to avoid duplicate map lookups.

 

I have tested the Scheme Editor, created a new scheme and edited it etc, and nothing seems to be broken, but you know the code better than I do so it might be worth a quick check.

[greebo]

I can't compile right now as my Linux runs crappier by the minute and even reboots don't help. It just kind of hangs at random times and accesses the hard drive like mad, but doesn't proceed a bit, especially during compile. It was better with Ubuntu 6.06 than it is now, but it doesn't need to correlate with the update... hmpf.

 

I just read through the code and it looks definitely better than before , I hope I can compile the thing in the evening, but I'm positive that nothing broke.

[OrbWeaver]

It seems that a few people are having difficulties with 6.10. My advice is never to upgrade too soon after the new version comes out, always wait a while for bugs to get ironed out and new versions of packages released.

 

Maybe I won't upgrade at all, just stick with the LTS versions (Long Term Support, should be slightly higher quality than the normal 6-month releases).

[greebo]

It seems that a few people are having difficulties with 6.10. My advice is never to upgrade too soon after the new version comes out, always wait a while for bugs to get ironed out and new versions of packages released.

 

Maybe I won't upgrade at all, just stick with the LTS versions (Long Term Support, should be slightly higher quality than the normal 6-month releases).

Yes, so it seems. I will re-install my system in the near future anyway, as the hard disk partitioning is not good at the moment (I just wanted to give it a try, so I installed it on a small, secondary 40 GB drive). If the performance is still not increasing after this re-install, I don't believe that I will spend too much time on Linux in the next year or so, as Windows seems to be far better performing on this very system.

[OrbWeaver]

If it's a small 40GB drive, that could be the root of your performance issues, particularly if it is on a slower bus/IDE channel/whatever.

[greebo]

I really hope the hard drive is the reason for the lame performance. Otherwise Ubuntu is no improvement in comparison to Windows for me at the moment. One spends already too much time waiting for the computer to do his job, I don't want to increase this time even more...

 

Anyways, it seems everything is working with DarkRadiant, thanks for the changes! Is there anything missing for version 0.7.0?

[OrbWeaver]

Anyways, it seems everything is working with DarkRadiant, thanks for the changes! Is there anything missing for version 0.7.0?

 

Looks like everything is in order. I guess I had better do some regression testing as well, i.e. make sure DarkRadiant can load/save all of the existing maps without crashing etc.

[angua]

I'm using the new version of DarkRadiant, bonehoard can be loaded and saved without any problems (apart from the fact that it takes a loong time for loading...)