Game performance - then & now - how much "optimization" have been performed ?

[MinhPham]

So ... trying to make the long story short, i started a new asteroid using the latest non-DLC version. The experience is almost the same except for extra stuffs like i had to "deep freeze" the foods, and must take care of floating chlorine / natural gas. Now the colony is over 500 cycles old, it's noticeable slow and i check the FPS count, 20 ! Here's a screenshot of the 29 dupes colony with barely anything built, yet it have 20 FPS performance.

For further investigation, I went back in time, grab a save file of a game that the younger me was playing, and load it to test, 14 FPS !

Then i remembered it wasn't that bad when i was still playing this old colony, i switched to the pubic_previous_version, it was 21 FPS !

 

Please, Klei, i love everything about this game except for the performance (and probably the never-fixed-bugs). Please do a better job at "optimizing" the game since i never really finished a game (except for the minibase one), most of them are FPS-death

[OxCD]

Old save aren't that much reliable imo, because "I think" there's some stuff inherited from an older version of the code, some optimization flaws from an ancient era tied to the version when the save was started.

 

But any test made with a recent save should be relevant, even if of course it's still relative to the machine behind.

Last time I played with my last heavy save, started years ago, I never went over 10fps, mostly around 6fps, some drop hitting 2fps.

It's been many years since I stop playing with standard map. Since then, only half-sized map or MiniBase. (Still, fps mentionned above took place in the half-sized one...). It helps... A little bit...

I'm very afraid they can't do much better.

Some guys probably a lot more skilled than me in computing, keep saying here or on Reddit than the problem is the core engine (terms might be wrong) which is used for ONI, that it cannot hold, in any way, enough computing to guarantee the flow. Single threading, if I recall correctly, was also mentioned plenty of time years ago.

All those things appart, I may say that I agree with your conclusion. The lag truly kill my experience.

I wish I would be more patient, and lenient to this, but I'm afraid I can't. (Well, playing nearly 1000 cycles at less than 10 fps isn't that bad, my love for ONI's gameplay carries more than expected). But now most of the time I always prefer playing game with slightly less options/complexity/mecanisms/graphics/or else, but running smoothly.

But about bugs... 100% agreeing. Old timed bugs are a thorn on my side, and I "feel" there's not much excuses.

Few of those now make me "rage" (exaggerated) quit quite easily. Klei seems to have chosen a long time ago to "move on", and to work on other projects.

[cpy]

Yeah I always said, if they fix FPS in the endgame I will die from starvation because I'd be only playing ONI. ONI is my MOST PLAYED steam game! Even though I rage quit when FPS gets below 30. How hard is it to optimize game? If you are not capable of optimizing game, then at least for the love of god decouple simulation with graphics so we can at least have smooth UI and orders if nothing else.

I was always asking for more FPS! Simulation can be choppy but not building. Building stuff in low fps mode is such pain.

[Coolthulhu]

Important note: dynamically changing the rate of simulation based on performance is not "optimization", it's an ugly hack that tries to hide bad performance by pushing it into later game, reducing reproducibility of bugs.

Looking (and clapping) at you, slicksters starving in 5kg/tile CO2.

[calibayzone]

20 minutes ago, Coolthulhu said:

Important note: dynamically changing the rate of simulation based on performance is not "optimization", it's an ugly hack that tries to hide bad performance by pushing it into later game, reducing reproducibility of bugs.

Looking (and clapping) at you, slicksters starving in 5kg/tile CO2.

Do we still have ranchers waiting forever for critters to path-find? Or did they at least make them get higher priority.

[Fradow]

10 hours ago, MinhPham said:

Please, Klei, i love everything about this game except for the performance (and probably the never-fixed-bugs). Please do a better job at "optimizing" the game since i never really finished a game (except for the minibase one), most of them are FPS-death

Performance is on the roadmap they posted a month ago. Since it wasn't mentioned on the only release so far, I assume they didn't get around tackling it.

If you follow the bug tracker, you'll notice they handled quite a few bugs, though mostly the quick fixes (missing or wrong texts and things like that) and bugs that lead to crashes. The bugs that don't make the game crash and aren't quick fixes didn't get much attention yet.

I too hope there will be some performance optimization. While, at some point, it is going to be a slideshow if you push the game long enough, there is definitely room for optimization that could push back that slideshow moment.

[MinhPham]

3 hours ago, cpy said:

 then at least for the love of god decouple simulation with graphics

It's true the game doesn't really need to run in a single thread, it's Unity main loop is single-threaded.

Last time i checked (welp, like 2 years ago) everything is relying on Unity objects/timers, that's what made the game single-threaded. We have entire renderer/game logic in a single CPU thread (except for the SimDLL does run on it's own thread).

But maybe like @OxCD said they might already moved on, just trying to get some more eggs from an old chicken :(.

[cpy]

I guess they only need to beat the refund timer on performance field and they're good. Also making game run better would not sell more copies. But even thought ONI is my MOST PLAYED game ever I will not buy more DLCs for this game since I will lag out and rage quit before experiencing all content from current version anyway.

ONI 2 would be wait for performance review kind of buy, game may be good but I'd rather have more polished experience.

Just think how great spaced out would run in if they were able to split maps into separate threads and everything! You could have colony of 100 dupes that would run smoother than current 10 dupes (provided you have 10 cores+ lol).

In the end I don't inhale copium and know that it's not very financially good investment to make game run faster if you already sold 95%+ copies that would ever sell.

I think their best call would be to make ONI2 and make it run great from start  than to fix this mountain of legacy code.

[tuxii]

I have been doing a lot of testing involving Pacu lately.

When there are few Pacu on a relatively empty map they'll almost immediately flop over to their tank.

Put 200 Pacu on the same map and the fries are sometimes 3 cycles old before they flop into the tank.  The tank is only 2 tiles away and then it's done moving for the rest of its life.  Granted this is at 10x or Ctrl-U speed.  Lowering the speed to 3x (maximum vanilla speed) the Pacu take a significant longer amount of time to flop over than when the population is low. This is probably why Pacu are coded not to die while flopping because if they did die while flopping, then Pacu population would be adversely affected by game performance in certain setups.

Even with one tile pools the performance impact of Pacu is high.

Vegetarian colonies are superior if we're talking about FPS.

 

[SharraShimada]

Guy buys a car. Guy puts a whole house on the cars roof. Guy complains the car wont drive fast anymore. 

From one fast look at your screenshots i can tell you, you´ve done every! single! mistake! there is to make when it comes to performance issues. 

[tuxii]

6 minutes ago, SharraShimada said:

From one fast look at your screenshots i can tell you, you´ve done every! single! mistake! there is to make when it comes to performance issues.

Blame the victim. 

[SharraShimada]

54 minutes ago, tuxii said:

Blame the victim. 

Nah. Not intended to do so. But if one is here over a year, i just assume this one has read some posts about do´s and donts when it comes to performance, if performance is an issue for him/her.  Judging from the screenshots 20FPS are VERY good, while he/she has done so many mistakes when it comes to best practice behavior.

[OxCD]

So the player has to adapt his gameplay, to game's limitation... ?

If you play a first person shooter, wouldyou accept to do not move your aim to fast, or fire to often, to save frames ?

If you play a strategy game, would you accept not building too much military production building to save frames ?

If you play a MMORPG, would you accept not using too much magic simultaneously during battle to save frames ?

 

The OP is playing the game. He's playing how he wants to play it. He's not even mentioning mods that may add calculation. 

He didn't fail the game, his duplicants are not all dead. So I think it's purely inappropriate to call it "mistakes", in the opposite of the "best practice".

A good practice allows you to finish the game, to improve your time, your strategy, to get better over competition, not to save frames.

[MinhPham]

5 hours ago, SharraShimada said:

Guy buys a car. Guy puts a whole house on the cars roof. Guy complains the car wont drive fast anymore. 

From one fast look at your screenshots i can tell you, you´ve done every! single! mistake! there is to make when it comes to performance issues. 

What  i am trying to complain is how the new version have only 2/3 frames performance compared to the old one, despite that they've posted about some performance "optimization" in pretty much every changelogs.

[SharraShimada]

6 hours ago, MinhPham said:

What  i am trying to complain is how the new version have only 2/3 frames performance compared to the old one, despite that they've posted about some performance "optimization" in pretty much every changelogs.

Ah, then i missunderstood you, i´m sorry for that. But thats easy to explain. The game has got many additions too.

Its simple. Take cars for example. Motors are way more efficient today, but they wont save you gas money. Why? Because the cars got bigger, heavier und have more gadgets that use power. That consumes all the optimisations and reduce them to a net zero value at the end.

[Saturnus]

1 hour ago, SharraShimada said:

Ah, then i missunderstood you, i´m sorry for that. But thats easy to explain. The game has got many additions too.

No it hasn't. The vanilla game has suffered in performance despite no additional content being added at all. That's the issue.

[gabberworld]

1 hour ago, SharraShimada said:

Ah, then i missunderstood you, i´m sorry for that. But thats easy to explain. The game has got many additions too.

Its simple. Take cars for example. Motors are way more efficient today, but they wont save you gas money. Why? Because the cars got bigger, heavier und have more gadgets that use power. That consumes all the optimisations and reduce them to a net zero value at the end.

what load you talk here? most off my cpu cores is idle when i play that in 12900k. that game is unbalanced by cpu load and that is it

soo you want talk the cars. i have 16 f1 fast cars at start line but only 4 is actually running because other 12 just not see the start flag

--

and yes guys and girls, even they type 2 cores as minimum you to need at least 6 core cpu when you run this game, 4 cores to game

+ 2

cores for other stuff like windows running in background or surfing at webpages at same time when you play

[Spoonwood]

1 hour ago, Saturnus said:

No it hasn't. The vanilla game has suffered in performance despite no additional content being added at all. That's the issue.

Food decay was added to the vanilla game.  Also, deodorizers requiring power and making heat.  Polluted oxygen in caustic biomes is more common than before, since previously a pincha peppernut wouldn't rot in chlorine, while now it will rot in hot chlorine.

[avc15]

what you will notice at very late progression - framerate goes to nothing but cpu utilization also goes down.

It's odd.

[gabberworld]

16 minutes ago, avc15 said:

what you will notice at very late progression - framerate goes to nothing but cpu utilization also goes down.

It's odd.

The problem seems to be that one cpu aka one core does the most work, when they not fix that there is no earth the pc what could handle this unless  you to have some super single core cpu 

[MinhPham]

2 hours ago, SharraShimada said:

Ah, then i missunderstood you, i´m sorry for that. But thats easy to explain. The game has got many additions too.

Its simple. Take cars for example. Motors are way more efficient today, but they wont save you gas money. Why? Because the cars got bigger, heavier und have more gadgets that use power. That consumes all the optimisations and reduce them to a net zero value at the end.

Either way computers are not cars. What the entire ONI community complaining is the entire game run in a single CPU core while they theoretically can run in multiple cores.

• Temperature calculations can't run in parallel (or DO they ?), have it run on one CPU core.
• Gas simulation also can't run in parallel (or DO they ?), give it a CPU core to run.
• Same for liquid simulation.
• Liquid pipes simulation ? Give each liquid loop a CPU to work with.
• Same for gas pipes.
• Also same for conveyor rails (oh no this one is still on C# and they haven't moved it to native SimDLL yet, or DO they, last time i checked was 2 years ago).
• Give each DUPE simulation a single CPU core, since they don't work together and don't have to be calculated in serial.
• Give each critters a CPU core too.
• Blah blah ....

All of that, combined with graphical rendering, run in less than 2 CPU cores. Why not 1 CPU ? Because most of the physic simulation (temp, gas, liquid) was moved to a native executable called SimDLL which have it's own CPU thread.

[avc15]

23 minutes ago, MinhPham said:

• Temperature calculations can't run in parallel (or DO they ?), have it run on one CPU core.
• Gas simulation also can't run in parallel (or DO they ?), give it a CPU core to run.
• Same for liquid simulation.
• Liquid pipes simulation ? Give each liquid loop a CPU to work with.
• Same for gas pipes.
• Also same for conveyor rails (oh no this one is still on C# and they haven't moved it to native SimDLL yet, or DO they, last time i checked was 2 years ago).
• Give each DUPE simulation a single CPU core, since they don't work together and don't have to be calculated in serial.
• Give each critters a CPU core too.
• Blah blah ....

I take issue with some of these things.

The entire game doesn't run in a single core, I can prove otherwise. But at the very least the multi threading isn't rigorous. It depends on your save but sometimes the "main" thread shrinks to below 50% of the total process load.

Now. Certain layers run in their own threads, but not per map or per loop as you have pointed out, rather, the whole layer (probably across all asteroids). To find the patch notes naming these changes I'd have to go dig them up (again; it's non trivial to search the patch history).

Also, if you wanted to split the simulation (main layer) up into separate simulations (one per habitable moonlet), you could actually do that. It doesn't matter that the map is one map (another thing that gets stated on this topic frequently is that this it can't be, because there's only one map). It does matter that there is a boundary where the different simulations can only interact through specific interfaces (eg divided by neutronium, can only cross the boundary with rockets, supply teleporters, etc). Because such a boundary exists, each layer could be run in separate threads per moonlet including the main simulation. Klei opted not to do that; they probably had to stop somewhere, and the threading they did was a substantial improvement at the time.

Anyway, I have to stop somewhere, too. I'll get off here for now.

 

[gabberworld]

2 minutes ago, avc15 said:

I take issue with some of these things.

The entire game doesn't run in a single core, I can prove otherwise. But at the very least the multi threading isn't rigorous. It depends on the colony but sometimes the "main" thread shrinks to below 50% of the total process load.

Now. Certain layers run in their own threads, but not per map or per loop as you have pointed out, rather, the whole layer (probably across all asteroids). To find the patch notes naming these changes I'd have to go dig them up (again; it's non trivial to search the patch history).

Also, if you wanted to split the simulation (main layer) up into separate simulations (one per habitable moonlet), you could actually do that. It doesn't matter that the map is one map (another thing that gets stated on this topic frequently is that this it can't be, because there's only one map). It does matter that there is a boundary where the different simulations can only interact through specific interfaces (eg divided by neutronium, can only cross the boundary with rockets, supply teleporters, etc). Because such a boundary exists, each layer could be run in separate threads per moonlet. Klei opted not to do that; they probably had to stop somewhere, and the threading they did was a substantial improvement at the time.

Anyway, I have to stop somewhere, too. I'll get off here for now.

 

noone talks that it runs at single core but one core gets the 100% hit, while that could be balanced as well

[avc15]

3 minutes ago, gabberworld said:

noone talks that it runs at single core but one core gets the 100% hit, while that could be balanced as well

Except this is a rather common claim on these forums, even sometimes repeated by veterans from early early access.

Including the post I replied to here.

19 minutes ago, MinhPham said:

What the entire ONI community complaining is the entire game run in a single CPU core

 

[MinhPham]

6 minutes ago, avc15 said:

I take issue with some of these things.

The entire game doesn't run in a single core, I can prove otherwise. But at the very least the multi threading isn't rigorous. It depends on the colony but sometimes the "main" thread shrinks to below 50% of the total process load.

Now. Certain layers run in their own threads, but not per map or per loop as you have pointed out, rather, the whole layer (probably across all asteroids). To find the patch notes naming these changes I'd have to go dig them up (again; it's non trivial to search the patch history).

Also, if you wanted to split the simulation (main layer) up into separate simulations (one per habitable moonlet), you could actually do that. It doesn't matter that the map is one map (another thing that gets stated on this topic frequently is that this it can't be, because there's only one map). It does matter that there is a boundary where the different simulations can only interact through specific interfaces (eg divided by neutronium, can only cross the boundary with rockets, supply teleporters, etc). Because such a boundary exists, each layer could be run in separate threads per moonlet. Klei opted not to do that; they probably had to stop somewhere, and the threading they did was a substantial improvement at the time.

Anyway, I have to stop somewhere, too. I'll get off here for now.

 

Last time i checked the entire game (well, like 2 years ago, but i don't think there's much of a change, and except for physic simulation is native code) is managed by Unity Engine, or i would say everything they defined in code as GameObject, and loops that do the actual game simulation is run on Unity MonoBehavior object. And Unity main loop that work with these things is single threaded.