Small bugs with 0.4.5 prerelease

[raptor]

Hi, I noticed a couple of possible regression when testing the most recent release (release-0.4.5 branch, Linux, openSUSE 13.2 x86_64):

1. Adjusting the font size does not adjust the font in the sitrep, even after restarting the game.
2. The sensor range circles do not 'merge' any more.

The attached picture shows both.

[raptor]

Sorry for double posting -

Found another:

3. Since the start of the game, Exobots show up under 'planet suitability' (in addition to humans) even though I haven't researched them yet.

[Dilvish]

1. Adjusting the font size does not adjust the font in the sitrep, even after restarting the game.
2. The sensor range circles do not 'merge' any more.
3. Since the start of the game, Exobots show up under 'planet suitability' (in addition to humans) even though I haven't researched them yet.

3. is 100% intended; since it's essentially under your control when you research that tech, we wanted you to be able to make the assessment beforehand about how helpful it would be.

1. Is pretty much intended, but perhaps we should rethink it and at the very least if should get an entry in the Pedia->Interface->Hidden_Settings page. There is a config.xml setting for sitrep size; and there is a forum thread with more information on the rationale.

2. Wow, I'm surprised to see that. I'm not finding any recent changes that could have done that. Did the problem start from the outset, or just develop late in the game? Did you have a lot going on (either a huge FO game, or also stressing your graphics card on something else?) Did you restart the game, or a smaller game, and see if it still happened? Also, just out of curiosity, could you report the value for detection-range-opacity in your config.xml file?

[Geoff the Medio]

2. The sensor range circles do not 'merge' any more.

Still work as expected (merging) for me...

[Vezzra]

2. The sensor range circles do not 'merge' any more.

Still work as expected (merging) for me...

Same here.

Issue seems Linux specific - any other Linux users seeing that issue?

[Dilvish]

Issue seems Linux specific - any other Linux users seeing that issue?

When I said "Wow, I'm surprised to see that." I didn't mean I was experiencing it also, I just meant I was surprised to see the screenshot. The last change to this section of MapWnd was two years ago when I fixed the detection circle overlaps, nor does it look to me like any of Geoffs recent draw optimizations touched any of the GG code used here.

That's why I was questioning raptor about how much stress his graphics card might have been under.

Raptor, looking back at your post history I see you've experimented with a lot of editing to get better performance. Could you tell me what is your full line in MapWnd.cpp which starts with "#define USE_STENCILS" ? Is it possible that some of your experimental performance tweaks got into the code you compiled for this?

[AndrewW]

Issue seems Linux specific - any other Linux users seeing that issue?

Haven't seen it myself.

[adrian_broher]

Can't reproduce this either with stock configuration

[raptor]

Code: Select all

#define USE_STENCILS 1

Hmmm... I was experimenting with performance improvements to the circle-drawing algorithms (mostly for the tech-tree rounded rectangles). I did a complete revert with git before I did a build, and I have no modified files. I just did a full recompile and it did not fix it. See below.

I've noticed that sometimes freeorion doesn't properly recompile all its dependent classes when changes are made - are you all doing full recompiles? My experience has been that CMake/make normally detects any file change correctly recompiles any dependent classes, etc., but something is odd with the freeorion build system. I do an out-of-tree build, too.

[Vezzra]

Can you try to narrow down which commit introduced this issue for you?

[Dilvish]

Code: Select all

#define USE_STENCILS 1

That's as it should be. But what you show is exactly the behavior that comes from this being set to 0. The stencil operations are performed by your graphics card, which is why I had been asking if it might have been overloaded. I'm not sure if it would be possible to change graphics cards settings that might have affected this issue.

I did a complete revert with git before I did a build, and I have no modified files. I just did a full recompile and it did not fix it. See below.

Do you use a git GUI? Is it possible you might have done a git rm on some modified file, so it's not showing up for you anymore? Perhaps you should try a fresh git clone.

I've noticed that sometimes freeorion doesn't properly recompile all its dependent classes when changes are made - are you all doing full recompiles?

I don't normally, but I did just now and it still works fine for me.

From everything I've tracked down, the code that handles this hasn't changed in two years; I very strongly suspect it's some other change at your end.

[raptor]

Found another bug:

4. Clicking the window manager 'X' (close window) when in-game will spike the CPU and not close the process. I have to kill -9 freeorion. (Linux)

As for the circle problem, I'm still tracking it down but I've done lots of compiles/cleans. I did find that the circles do merge fine if I use the integrated intel chip to drive the game, but they don't merge when using the NVIDIA chip under certain conditions - I have an NVidia bumblebee setup on my Linux box:

- 'optirun ./freeorion' fails
- 'primusrun ./freeorion' works

This must be some driver + software issue with Linux bumblebee support.

I will continue bisecting and see where it may have broke.

[Dilvish]

Found another bug:
4. Clicking the window manager 'X' (close window) when in-game will spike the CPU and not close the process. I have to kill -9 freeorion. (Linux)

It works fine for me in Ubuntu. On rare occasions the server hangs for me if I quit while it's really busy with a big turn update. Try going to Options->Other and changing the number of Effects threads to 1 and see if that resolves it for you.

[raptor]

Having fewer effects threads did help a bit; however, I traced the major CPU usage due to the same graphics driver issue as the unmerged circles. So disregard my #4.

After more digging, I'm confident the circle merge issue is wholly a driver problem on my end which probably appeared with a recent kernel update. I had originally thought it was due to the buffer changes in CUIDrawUtil, but that didn't appear to be so.

I'm sorry for the bad reports; thanks for taking the time to respond.