Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weltall]

I am sorry if this is not the place I should ask, but I did not see where else I could. I just got the game so I am totally unfamilliar with how it works and I just know that Minecraft that is a Java game too, lags if modded too much.

I am on 0.65.2a and
LazyLib
MusicLib
ShaderLib
TwigLib
Starsector+
Nexerelin
Common Radar
Console Commands
Citadel
Exigency
Interstellar Imperium
SCY
Shadowyards Reconstruction Authority
Templars

as mods.

I am on a
Intel Core2Quad q9400 3.2GHz
8GB ram
ATI R9 290 3GB VRAM
Windows 7 Home Premium

The area around my main "player" planet became from normal to really laggy, since I deded to take over 2 new starsystems. I took one at almost the beginning of the game and that did not bother it.

I have to say what I did lately is to fill up my storage with a lot of captured ships, sell large amounts of different weapons to the player faction main planet and fill in the Omnifactory with any kind of weapon I had, so I would only go to refit my ships there.

The only sluggy moments I had up to capturing the last pirate base, was when in battles it was a chaos with ships and explosions and stuff. It is not bad that I can;t live with it, but I am wondering if I should not sell too many weapons in omnifactory or maybe not store too many ships or sell too many weapons in my main planet. Well it is either that or the fact that around the main planet it is covered in small and big fleet orbiting it, making flying around my planet really slow (about 13-17FPS). Not sure if the sleets outside the planet affect the planetary interface.

[Alex]

I'd noticed myself while testing a bug with a Nexerelin save (plus Shadowyards, ShaderLib, and LazyLib as the only other mods) that it seemed on the slow side - consistently running at ~45 fps with no idle, where it runs 60 fps >50% idle sans mods. My guess is one of the mods involved either just needs to do that much computation, or is perhaps doing something inefficiently. Didn't do much investigating, though.

[SpacePoliticianAndaZealot]

Starsector is single-thread, for the most part.  The best CPU for the game is a 6700K overclocked to 5+ GHz.

[speeder]

I'd noticed myself while testing a bug with a Nexerelin save (plus Shadowyards, ShaderLib, and LazyLib as the only other mods) that it seemed on the slow side - consistently running at ~45 fps with no idle, where it runs 60 fps >50% idle sans mods. My guess is one of the mods involved either just needs to do that much computation, or is perhaps doing something inefficiently. Didn't do much investigating, though.

I don't released my mod yet, but I am worried about the performance it might have...

Any simple way to profile StarSector?

[Schwartz]

It's probably the ATI R9. Great card, bad OpenGL performance for this particular game. Symptoms include below-60 FPS in ostensibly empty and light load scenes as well as heavy slowdowns in battles. With many objects in particular, like missiles.

[Weltall]

It is so nice to see such an alive forum. Thanks for all the answers! The game runs fine since 30 FPS for me is the norm for games. If anything it just looked that taking over planets or selling a lot of stuff make it slower XD I get from 45-60 FPS through the game and thats fast for me.

Well I definitely do not have a 5GHz CPU and I imagined as much, since minecraft seems to be the same, except when some mods change the way the map loads to make it load faster, which can result is many crushes and corruption.

T_T ATI always has sucked when it came to some things like that. Well I got it cheaply, so I will not complain for the battles, which personally I find a bi amusing to see the slowdown due to the huge amount of explosions

Does anyone know if selling too much stuff or storing them can result to slowdowns, especially in Omnifactory that has to keep resupplying so many things. Still nothing gamebreaking since the slowdown I experience is only around my homeplanet.

[LazyWizard]

Does anyone know if selling too much stuff or storing them can result to slowdowns, especially in Omnifactory that has to keep resupplying so many things. Still nothing gamebreaking since the slowdown I experience is only around my homeplanet.

The current version of the Omnifactory updates once per in-game day, so any performance problems would manifest as a momentary freeze every few seconds without affecting the framerate otherwise.

[Alex]

Any simple way to profile StarSector?

One could always hook up jvisualvm to it and profile it.


Also, there are two SettingsAPI methods:
void profilerBegin(String id);
void profilerEnd();

Those can be used to figure out how long a code segment takes, and it only counts frames where the frame rate is below 60. For example usage, see com.fs.starfarer.api.impl.campaign.missions.MarketProcurementMissionCreator.jav a

The collected data will be printed to the log when the game exists, under the campaign state section.
Edit: it's probably not a good idea to slap it on *everything* and leave it in. Generally, if you're going for more detailed metric collection, you'd remove/comment these out when you're done.

[Schwartz]

Would it help if some of us with 'problematic' graphics cards did this profile thing? Even if the OpenGL implementation is flawless, there could still be done something to patch around ATI bottlenecks or overheads right?

[Weltall]

The current version of the Omnifactory updates once per in-game day, so any performance problems would manifest as a momentary freeze every few seconds without affecting the framerate otherwise.

Thanks a lot for the info LazyWizard and for of course all the awesome mods you have created! It is good to know it is not Omnifactory and I can feed it as many weapons as I find

Would it help if some of us with 'problematic' graphics cards did this profile thing? Even if the OpenGL implementation is flawless, there could still be done something to patch around ATI bottlenecks or overheads right?

I would call that a miracle for sure. I know that in minecraft, be it I use the original OpenGL or optifine's lightweight openGL option, supposed to make the game run much faster, it slows down the game a LOT.

[Alex]

Would it help if some of us with 'problematic' graphics cards did this profile thing? Even if the OpenGL implementation is flawless, there could still be done something to patch around ATI bottlenecks or overheads right?

Unfortunately, I doubt it. Profiling with jvisualvm is unlikely to produce useful results for graphics stuff because it slows the game to a crawl altering the ratios of time spent in graphics and cpu, and the .profileBegin/End method wouldn't be fine-grained enough.

I do wish I knew what the bottlenecks there were, though, and it might still be useful to see the log output from a short-ish campaign run - i.e. start the app, load up a savegame, fly around for a bit until there's been some time at below 60 fps, exit out, and then send me the last section of the log - the lines (couple of hundred of them?) starting with com.fs.profiler.Profiler.

Then, same thing for a battle. Chances of producing something definitive are low (this usually works as an iterative process, narrowing down the potential issues, and paired with adjusting code between runs), but it may be worth a short anyway.

[Dark.Revenant]

I have a computer capable of profiling Starsector with reasonably high fidelity in real time (30+ FPS with vsync off), and largely the stuff in the campaign that eats up the most CPU are things like sporadic large operations (like O(n^2) operations, search-by-name, etc.) and fleet AI.  The latter causes frame rate to drop, and the former causes studdering.  GC also causes a fairly major hiccup, every once in a while that it runs.

Generally speaking, optimizing terrain rendering code and fleet AI calculations will save the most total CPU time, and limiting complex campaign scripts will improve overall perceived performance.

I'm not sure if staggering campaign scripts will help.  It will make hiccups less severe, but it makes them happen more often.  Best do it only if you can ensure that they can be split up enough to stay under 1/30 second for a single frame.  Running big simulations, like the Economy, in a thread pool, could significantly reduce these types of hiccups.  You might want to make a script hook type for the campaign that gets thrown in a thread pool (with info passed for executor count and index on advance()) so that some of the bigger operations can be done with extra power.

By the way, the campaign renderer for large fleets is expensive.  You might want to consider fading out small ships if the screen is populated with a lot of them.

[Alex]

If we're talking about vanilla (are we?), the economy sim doesn't take too much cpu and it's spread out over multiple frames in a way that should avoid any hiccups.

Good point re: fleet AI; I should take a look at that - confirmed and noted. Might be some low-hanging fruit there as it's code that hasn't had an optimization pass.

Was there any specific terrain rendering you had in mind? The one thing I'm aware of is rings (it renders the entire thing regardless of how much of it is on-screen), but that doesn't seem to have been a problem. Other stuff seems to be fairly clean, given that it's using immediate mode. (And, I mean, it could use glDrawArrays etc, but in my experience that doesn't help at all for the small numbers of vertices that are involved.)

... you know, let me move this to Modding. Seems a bit more appropriate for something that's getting technical.

You might want to make a script hook type for the campaign that gets thrown in a thread pool (with info passed for executor count and index on advance()) so that some of the bigger operations can be done with extra power.

That'd require making the engine thread-safe.

By the way, the campaign renderer for large fleets is expensive.  You might want to consider fading out small ships if the screen is populated with a lot of them.

Yeah, it's pretty expensive. Spent a bunch of time getting it to run faster, so it's a bit dry on easy fixes...

(Also, note that it doesn't show every ship - limits to a total of 15, iirc, with some small and some large to create a balanced-looking fleet. Interesting suggestion, though - have a feeling I'll have to look at this again at some point.)

[Dark.Revenant]

Was there any specific terrain rendering you had in mind? The one thing I'm aware of is rings (it renders the entire thing regardless of how much of it is on-screen), but that doesn't seem to have been a problem. Other stuff seems to be fairly clean, given that it's using immediate mode. (And, I mean, it could use glDrawArrays etc, but in my experience that doesn't help at all for the small numbers of vertices that are involved.)

Well, the hyperspace advance loop is rather expensive compared to the rest of the terrain.  But I meant more that the large amounts of immediate mode switching causes the general scenario with lots of stuff visible onscreen to eat CPU.  Not really sure if there's a way to avoid it - other than just optimizing such things as best as you can, in general.

Note: immediate mode switching is expensive.  If there's some scenario where there are tons of a similar thing being rendered, there might be a significant performance gain by using drawArrays or at least putting them under one begin/end block.

[Alex]

Ah, thanks!

Yeah, the hyperspace advance()... has quite a bit to do. It's going to be interesting once the Sector area gets bigger.

Well, the hyperspace advance loop is rather expensive compared to the rest of the terrain.  But I meant more that the large amounts of immediate mode switching causes the general scenario with lots of stuff visible onscreen to eat CPU.  Not really sure if there's a way to avoid it - other than just optimizing such things as best as you can, in general.

Note: immediate mode switching is expensive.  If there's some scenario where there are tons of a similar thing being rendered, there might be a significant performance gain by using drawArrays or at least putting them under one begin/end block.

Right, gotcha.