FreeOrion

Forums for the FreeOrion project
It is currently Mon Dec 11, 2017 7:48 am

All times are UTC


Forum rules


Always mention the exact version of FreeOrion you are testing.

When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.



Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Sep 11, 2015 11:22 am 
Offline
Space Krill

Joined: Fri Sep 11, 2015 11:02 am
Posts: 8
I wrote down a lot of little irritations and made a nice XML document, though for some reason it doesn't render right in Chromium, so use Firefox.

There's a few bugs in there too. I have tried to categorize the importance and complexity of each one, too.

Since that's a github repo, you can comment on the diffs or even submit PRs, but I'm also hanging out on IRC.

Since these are mostly feature requests, version isn't quite as important, but I have played from the Debian packages:

  • 0.4.4-2+deb8u1
  • 0.4.4+git20150327-2
  • 0.4.5~RC1-1
  • 0.4.5-1

but (with the exception of the top of the table which needs to be updated/merged) must of it was with RC1.


Top
 Profile  
 
PostPosted: Fri Sep 11, 2015 11:52 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12039
Location: Munich
By scrapping an incomplete building, do you mean something other than removing it from the production queue (which can already be done)? Presumably you mean add a "Scrap"-like right click popup menu command to do this?


Top
 Profile  
 
PostPosted: Fri Sep 11, 2015 12:39 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3286
Geoff the Medio wrote:
By scrapping an incomplete building, do you mean something other than removing it from the production queue (which can already be done)? Presumably you mean add a "Scrap"-like right click popup menu command to do this?

That's actually I'd quite like, if you conquer a planet and it's building stuff you don't want going into the production queue can be annoying and definitely causes lag.

Reading through the whole list, some I agree with, others not so much or could be solved in different ways, I'll figure out how to comment on it later.

_________________
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.


Top
 Profile  
 
PostPosted: Fri Sep 11, 2015 8:14 pm 
Offline
Space Krill

Joined: Fri Sep 11, 2015 11:02 am
Posts: 8
Link to comment: https://github.com/o11c/o11c.github.io/ ... b1beb5fL57

The most pressing issue is probably the "CPU usage even when not visible", since right now I have to work around it with a bunch of `killall -STOP freeorion` and `killall -CONT freeorion`.

At a quick glance CPU usage does seem better in 0.4.5 release than in RC1 (~40% instead of ~80%), but that might just be because I'm testing a fresh game, and there's still not the expected decrease when the window is *not* visible.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 1:04 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12039
Location: Munich
Stopping rendering in a "nice" way, so that it resumes rendering promptly, isn't simple to set up. But the latest master revision lets you specify separate max FPS for when the game window has or doesn't have focus. Dropping the non-focus limit to 5 or fewer FPS substantially reduces the CPU use for me.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 2:30 am 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
Geoff the Medio wrote:
Dropping the non-focus limit to 5 or fewer FPS substantially reduces the CPU use for me.
Perhaps the default value for the non-focus limit should be in the 1-5 range?

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 3:54 am 
Offline
Space Krill

Joined: Fri Sep 11, 2015 11:02 am
Posts: 8
I don't care about the not *focused* case, I care about the not *visible* case. Specifically, whenever it is minimized or on a non-visible desktop (which generates the same events as being minimized).

In X11 terms, when you receive an UnmapNotify event, you should not be rendering at *all* until the next MapNotify event. Since you're not doing damage-based rendering, even if your code is insane, this part could be as simple as keeping a bool flag and early-return'ing at the beginning of the render function - though you really should stop the redraw call from happening at all (stop generating ticks somehow? Why are there ticks at all when there are no active animations?).

(If you do switch to damage-based rendering, which would be a huge win for the kind of rendering that FreeOrion does, it's as simple as treating the whole window as damaged when MapNotify happens). In that case, you take action *only* when a network, input, or timed damage events from animations.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 6:06 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12039
Location: Munich
o11c wrote:
I don't care about the not *focused* case, I care about the not *visible* case.
I realize that, but as I wrote above, stopping rendering in a "nice" way, so that it resumes rendering promptly, isn't so simple to set up. Minimizing the FPS while not focused gets you most of the way there; 0.5% or 1% CPU use is a lot less than the ~15% I get at nominal 60 FPS.
Dilvish wrote:
Perhaps the default value for the non-focus limit should be in the 1-5 range?
Play around with it if you'd like; limiting the FPS so much does have minor annoying consequences, particularly to mouse cursor movement / rendering.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 8:26 pm 
Offline
Space Krill

Joined: Fri Sep 11, 2015 11:02 am
Posts: 8
Okay, looking at the code, it shouldn't be too hard:

  • In GG/src/EventPump.cpp:
    • in EventPumpBase::LoopBody, remove the call to gui->Wait, instead return the value at the end (note that this means switching the order of the logic, but that won't have any visible effect).
    • in {,Modal}EventPump::operator(), pass the returned value as an argument to gui->HandleSystemEvents
  • In GG/src/SDL/SDLGUI.cpp:
    • In SDLGUI::HandleSystemEvents, replace the call to SDL_PollEvent(&event) with SDL_WaitEventTimeout(&event, timeout) but only the first iteration of the loop.
    • In SDLGUI::HandleSystemEvents, add case labels for SDL_WINDOWEVENT_SHOWN and SDL_WINDOWEVENT_HIDDEN (or possibly SDL_WINDOWEVENT_RESTORED and SDL_WINDOWEVENT_MINIMIZED - under X11 they occur at the same time, but I'm not sure about Windows or mobile, reading the SDL source was not enlightening).
    • If you manage to switch entirely to damage-based rendering (which you really should!), also add a case for SDL_WINDOWEVENT_EXPOSED.

The worst thing that could happen is that you draw a frame more frequently than expected whenever events happen. This would actually *fix* the problem where limiting FPS makes the mouse jerk.

In a damage-based system you would call it "animation quantum" though.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 11:22 pm 
Offline
Space Krill

Joined: Fri Sep 11, 2015 11:02 am
Posts: 8
Expanding on my "research priority levels" item:

Instead of having all researched items in one queue, put them in four:

  • On high: always respect the user's order. When adding an item, place it in the last position such that the most items will be completed as soon as possible.
  • On medium: every turn or when adding items, jiggle the order to try to get all items done at the same time. For example, it is not useful of I get my new shields if my lasers are still researching.
  • On low: respect the user, but jiggle when adding items (same logic as high, but below medium, for stuff you don't care about when exactly it is done), e.g. "I need Active Radar sometime before all the auto stuff".
  • On auto: attempt to research *all* technologies. This probably uses the same algorithm as Medium. Starting at the end, add the most expensive per-turn leaf technologies in order, mark a tick off, then treat prerequisites as leaves once they're fully ticked off. The major advantage of this order is so that people don't forget how many prerequisites there are for the endgame ships (the longer the chain of dependent technologies, the earlier auto will put it).
  • On disabled: put technologies here if you don't want to ever research them, e.g. to block the Singularity of Transcendence because combat victory is more fun.

Most likely the strategy for each of the 3 user categories should be customizable to prevent confusion; the strategies I marked are what *I* would use.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 11:48 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3286
o11c wrote:

For everyone else's benefit, I've gone through the stuff I understand and/or have opinions on and commented there, but some of it is way over my ability to code and some is worth separate threads.

_________________
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.


Top
 Profile  
 
PostPosted: Sun Sep 13, 2015 12:21 am 
Offline
Space Krill

Joined: Fri Sep 11, 2015 11:02 am
Posts: 8
Expanding on my "new production window" idea:

The current method of "select a planet, then do production of an item there" is almost never what you want. More likely, you want to say "select an item to produce, and *then* choose where to produce it", which requires an entirely different sort of window.

Example use cases:

  • Combat: I need more ships for the South Fleet, build them at the southernmost Mu'Ursh shipyard.
  • Outposts: I want to create an outpost here, where is the nearest shipyard?
  • Terraforming / Gaia Transformation: I want to build one, show me the best place (sort objects by biggest).


Top
 Profile  
 
PostPosted: Sun Sep 13, 2015 4:08 am 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
o11c wrote:
Instead of having all researched items in one queue, put them in four:
I don't think there is any real chance of a system like this being adopted-- it may be personally appealing to you (and you might be able to implement it for yourself if you really want), but I don't see any significant benefit from it; certainly nothing that comes near to justifying the extra complexity of adding three additional queues. I'll note that you didn't even attempt to address how you might divvy up research points between the queues-- there are of course various ways it could be done, but the fact that such a critical point was too much nuisance for you to even try describing should be a clue that the overall proposed system is too complex.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Sun Sep 13, 2015 3:53 pm 
Offline
Space Floater

Joined: Fri Aug 14, 2015 8:29 pm
Posts: 47
o11c wrote:
  • Combat: I need more ships for the South Fleet, build them at the southernmost Mu'Ursh shipyard.
  • Outposts: I want to create an outpost here, where is the nearest shipyard?
  • Terraforming / Gaia Transformation: I want to build one, show me the best place (sort objects by biggest).


I second this.


Top
 Profile  
 
PostPosted: Mon Sep 14, 2015 1:12 am 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
Nexus wrote:
o11c wrote:
  • Combat: I need more ships for the South Fleet, build them at the southernmost Mu'Ursh shipyard.
  • Outposts: I want to create an outpost here, where is the nearest shipyard?
  • Terraforming / Gaia Transformation: I want to build one, show me the best place (sort objects by biggest).


I second this.

The last of these is quite easy to manage using the Objects window; I'm rather doubtful you could come up with a more efficient way to accomplish this than by using that.

The second one is a pretty simple visual inspection task on the MapWnd-- human visual pattern matching is pretty darn good.

The first one is a more complex version of the second, which, if your memory fails you would currently require a bit of checking to see which of the shipyards was Mu-Ursh.

Did either of you have any thoughts on what UI interaction could actually provide a better path than is currently possible? Keep in mind that it should not require baking-in content details regarding specific ship hulls/parts (or building types) into the C++ UI (but allowing some level of configuration via information read from config.xml or from common_user_customizations.txt is OK).

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group