Which GUI lib is galciv4 using?

Not sure if this has been bought up before but the UI currently used in galciv4, which is presumably the exact same library being used in GalCiv3 (?), has a really hard time keeping up when the galaxy gets populated, to the point where it can't register a click properly and delays a full second before responding, a good reason to implement "repeat" options for all shipyard items.

It's not using Unity's IMGUI is it? that thing has a horrible cost for additional complexity and it shares the main thread so as your game goes up in processing your UI gets increasingly terrible responses (and the poor taxation on the minds of the devs who have to use it :P ), there's some wild UI libs out there worth checking out, like PowerUI that'll consume 1ms and give you real JS/jQuery/callbacks/CSS selectors so web dev experience (which should be most of this earth at this point) can contribute to your project, throw in bootstrap or something, and away you go. I used it for a dev layer in a game and was blown away by how wonderful it was to use.

I'm assuming this is using Unity, in fact a fork of a GalCiv3 build, or is this all through UnrealEngine?

I hope it gets replaced, whatever it is, it's going to prevent any large games from being played to conclusion.  With the size extensions to GalCiv3 this became painfully obvious as the engine just couldn't handle the larger game worlds and the UI would hang frequently for several seconds when trying to add things to build queues etc.

11,015 views 8 replies
Reply #1 Top

GalCiv has its own engine.

There’s no magic bullet for dealing with tens of thousands of entities. Only vigilant tuning and profiling.

Reply #2 Top

I just mean the UI itself shouldn't be impacted by the depth of your data stores, if injecting an item into a list has a 2000ms cost that's fine but you don't have to inject it in realtime, it doesn't have to block the UI while it does it. That's what's currently happening though.

Reply #3 Top

Quoting bradzoob, reply 2

I just mean the UI itself shouldn't be impacted by the depth of your data stores, if injecting an item into a list has a 2000ms cost that's fine but you don't have to inject it in realtime, it doesn't have to block the UI while it does it. That's what's currently happening though.

Sure it can.  The problem is that there are places where they do it in real-time instead of sending a message. It’s a crappy hold over from gc3.  It’s not an engine issue, it’s a bad coding issue.

Reply #4 Top

That said, your post motivated me to look more into this issue.

if (usage == StatUsages::Actual )
{
this->SetShouldRecalc(TRUE);
}

This is the problem.  So when you build a thing, the game is calculating the stats to adjust whether you still have the resources for the next thing you might want to queue.

However, there are ways to thread this or make it deferred.

+1 Loading…
Reply #5 Top

Yep, I guess i was more or less just wanting to know if anyone thinks this is something worth fixing, UI lag kills me :) Thanks for taking the time :)

Playing v80 currently, this release seems pretty quick so far, might be that i haven't left the starting cluster and only have 10 shipyards so far. 

Reply #6 Top

Quoting bradzoob, reply 5

Yep, I guess i was more or less just wanting to know if anyone thinks this is something worth fixing, UI lag kills me :) Thanks for taking the time :)

Playing v80 currently, this release seems pretty quick so far, might be that i haven't left the starting cluster and only have 10 shipyards so far. 

Thank you for posting.  Without your post, I wouldn't have taken a look into it.

It's one of those simple calls (updatestats()) that seems harmless and then balloons (and has ballooned as more and more stuff got attached to it).

In the next update, even late game, adding a typical ship to the queue will be instantaneous as well as adding new projects.  Only if they require a special resource will there still be a pause and even that will be a lot less.

 

Reply #7 Top

<3   thanks man, that's a huge game changer for me :)

Reply #8 Top

Just thinking out loud here - why not have a two tier system for builds, active and deferred, most of 4x is really about planning and less about doing, things take multiple turns to play out, so to cut down on micro if you allowed people to start build a thing as a "deferred build" without having the resources then it can inject them into the queue once it has the resources, and usually that's the next turn anyway. Just let the queue handle it first come first served.  This would prevent having to fiddle about and constantly false start on plans when you've already made a decision but realise you can't action it because the resources don't exist yet. A single turn can take an hour, in that time you can have a lot of false starts due to resources, sometimes that makes you just want to rush the the turn, which isn't good :)