Jump to content

Suggestions for Frame rate improvements


Recommended Posts

Game's way too laggy. Guess its my 4th post or so in this.

I can barely research 15 techs in the game before it starts to drop to 10 fps. More map exploration = game kills interest to play by just being unplayable.

So, some of my suggestions are as follows:

1. Liquid Logic is hogging system (i'd say atleast 5%). This is coz liquids in ONI are being continuously re-calculated. I can guess this by the constant and unwanted weight changes in the tile as time passes. Liquids are not in a constant flux of motion. Once they settle down, they don't move much unless they are not bounded on either side. In ONI, even liquid in a reservoir is continuously moving around.

2. Use a different logic to simulate areas which are not viewed by the player. Since exploring new areas slows PC more, I believe that everything is constantly being simulated in real time. I'd be better if a way is found to isolate the rendering to only areas that the player sees in the screen. Or even better, only where the mouse pointer is. (Not sure how it'll be viable though, coz in long term, all objects interact with all other objects in the game)

3. Germs in the game are eating the CPU resources (atleast 2-4%). Their values are constantly recalculated. If the polluted liquid has multiple modifiers, all modifiers can be aggregated to give a single %increase or decrease. I believe its currently applying all modifiers individually to the number of germs in the time, leading to multiple layers of processing instead of one. If liquid is heated to 70 degrees, its dying. But if its in a solid that reduces count by 3% per cycle, both are applied one after the another. I'd be better if both modifiers are applied in one go.

4. I believe the heat exchange logic is the one taking the most processing load in the game(atleast 30+%). I think its better to have a separate software thread exclusively for it. Any interaction between dupes or autosweepers will first consult the thread if its working on it and then move the object.

5. EDIT1: Apparently pathfinding is bad as well. I believe pathfinding is easy to implement in a separate thread and will take the load off the main thread. Also, we can have some intermediate animations as if the dupe is thinking when the pathfinding algorithm is finding the optimal route.

6. EDIT2: Atmosphere is another resource hogger. Again, its constantly getting recalculated. Why not implement a system which auto evens the atmosphere instead of the current system of averaging the masses+temperature+etc over and over again until it stabilizes? Even then, I believe the game is constantly recalculating the values repeatedly.

And finally, @Ipsquiggle, @Cheerio...etc, Game is utterly unplayable even in a really modern computer with an i5 6600, 16GB RAM, GTX 1060 6GB during the later stages of the game. I understand its early access and all, but it'll be a LOT nicer to know if you are working on optimizations in the 8 week updates.

I can play assassin's creed origins, Rise of the Tomb Raider, etc etc at 50+FPS in my computer.

I'm still crawling at 2 FPS in ONI at later stages when it should be runnable damn easily!!!

Link to comment
Share on other sites

On 11/7/2018 at 5:05 PM, ArunPrasath said:

4. I believe the heat exchange logic is the one taking the most processing load in the game(atleast 30+%). I think its better to have a separate software thread exclusively for it.

Why only one thread? On a CPU with 4 physical cores and 8 logical ones (Hyper-threading has 2 logical cores per physical core), wouldn't 8 threads be more appropriate? Since tiles can only exchange heat with adjacent tiles, it should be possible to split the calculations evenly among all 8 threads, without the danger of a race condition (which would cause data corruption).

For example, when calculating horizontal heat exchange (heat exchange between tiles to the left and to the right), all threads could first calculate all tiles whose x coordinate is odd (not dividable by 2) and, after all threads are finished, do the same for the tiles whose x coordinate is even (dividable by 2). That way, there is no danger of a race condition between threads, because no two threads will ever by writing to the same tile at the same time. This danger would only exist if the tiles with an even and odd x coordinate were done at the same time.

Once all threads have finished with the horizontal heat exchange calculations, the vertical heat exchange calculations (heat exchange between tiles to the top and bottom) can be done. These are done the same way as above, except that the y coordinate must be used in order to prevent race conditions.

The horizontal and vertical heat exchange calculations are not allowed to be done at the same time, because then there would be a danger of two threads writing to the same tile at the same time (i.e. a race condition), which could cause data corruption.

Doing the horizontal and vertical heat exchange seperately also has the advantage that this would allow SIMD instructions to be used efficiently (which are available in all modern desktop processors). This would also significantly speed up calculations.

Unfortunately, such optimizations are not as easy to implement in ONI, due to the limitations of the Unity Engine. In hindsight, I believe that it would have been better if ONI had been programmed in C++. The game Factorio, which is heavily optimized, was programmed in C++ for a reason.

However, the Unity Engine does allow the game to use external DLLs (which can be programmed in C++). That way, it would still be possible to implement all of this in the Unity Engine.

Link to comment
Share on other sites

Another major performance issue that was not mentioned is pathfinding of dupes.

Transit tubes already reduce the computational complexity of pathfinding, due to the reduced number of pathfinding nodes (when using heuristical pathfinding algorithms such as A*). However, this can be further optimized. For example, individual tube segments could be cached, as has been done for railroad track segments in the YAPF pathfinder of the open-source game OpenTTD.

Also, for paths that don't use transit tubes, something similar to RimWorld regional pathfinding could be implemented for optimization.

Link to comment
Share on other sites

7 hours ago, ArunPrasath said:

4. I believe the heat exchange logic is the one taking the most processing load in the game(atleast 30+%). I think its better to have a separate software thread exclusively for it. Any interaction between dupes or autosweepers will first consult the thread if its working on it and then move the object.

Well it might be done you could calculate the heat exchange in a seperate thread but write the result in the main thread +same for pathfinding thats the way i manipulate tiles in my mod and it works you know unity is not really thread safe and unity + threading = hell.

Maybe i even could simulate the heat exchange with a mod and look if i can disable the original but right now i hope they do it soon since they stated the change in the roadmap away from more content.

Link to comment
Share on other sites

4 hours ago, Rainbowdesign said:

Maybe i even could simulate the heat exchange with a mod and look if i can disable the original but right now i hope they do it soon since they stated the change in the roadmap away from more content.

Can you explain how you can do this? I'd love to give it a try myself!!

Frame rates are horrible and if the game only uses one thread, it'll never ever be playable in the real world.

Link to comment
Share on other sites

4 hours ago, ArunPrasath said:

Can you explain how you can do this? I'd love to give it a try myself!!

Frame rates are horrible and if the game only uses one thread, it'll never ever be playable in the real world.

I can explain a little on how to get and write the heat values.

 

You could read and do the calculation in one thread by iterating over the grid


            for (int i = 0; i < Grid.CellCount; i++)
                    calculate( Grid.Temperature[i]); 

 

And you could set it with a sim message when all calculations are finished in the original thread:

public static unsafe void ModifyEnergy(int gameCell, float kilojoules, float max_temperature, SimMessages.EnergySourceID id)
  which is in SimMessages

However as you can see that one is declared unsafe it uses pointers... I dont know how good the idea is to use it in bulk, maybe you should look into how the native system of heat works and make something similar in a thread or rewrite it to be less consuming.

What is more is that if you thread this you might want to look how good the heat stuff works out when a building emits heat.

While i may not be the right one to judge this my opinion with all that unsafe statements i think oni is far from being very stable to modifications and unoptimized.

Link to comment
Share on other sites

49 minutes ago, Rainbowdesign said:

You could read and do the calculation in one thread by iterating over the grid



            for (int i = 0; i < Grid.CellCount; i++)
                    calculate( Grid.Temperature[i]); 

Are you sure its just a single for loop? the grid is a m x n array of diggable elements/buildings. Also, there is a logic to transfer heat between dug materials and the ground.

Link to comment
Share on other sites

1 hour ago, ArunPrasath said:

Are you sure its just a single for loop? the grid is a m x n array of diggable elements/buildings. Also, there is a logic to transfer heat between dug materials and the ground.

This is not code from oni its from my mods i made a searcher that searchs elements on the map. i dont know the heat system i just gave you some idea where to start.

Link to comment
Share on other sites

On 07.11.2018 at 8:14 PM, Tekky said:

Why only one thread? On a CPU with 4 physical cores and 8 logical ones (Hyper-threading has 2 logical cores per physical core), wouldn't 8 threads be more appropriate? Since tiles can only exchange heat with adjacent tiles, it should be possible to split the calculations evenly among all 8 threads, without the danger of a race condition (which would cause data corruption).

For example, when calculating horizontal heat exchange (heat exchange between tiles to the left and to the right), all threads could first calculate all tiles whose x coordinate is odd (not dividable by 2) and, after all threads are finished, do the same for the tiles whose x coordinate is even (dividable by 2). That way, there is no danger of a race condition between threads, because no two threads will ever by writing to the same tile at the same time. This danger would only exist if the tiles with an even and odd x coordinate were done at the same time.

Once all threads have finished with the horizontal heat exchange calculations, the vertical heat exchange calculations (heat exchange between tiles to the top and bottom) can be done. These are done the same way as above, except that the y coordinate must be used in order to prevent race conditions.

The horizontal and vertical heat exchange calculations are not allowed to be done at the same time, because then there would be a danger of two threads writing to the same tile at the same time (i.e. a race condition), which could cause data corruption.

Doing the horizontal and vertical heat exchange seperately also has the advantage that this would allow SIMD instructions to be used efficiently (which are available in all modern desktop processors). This would also significantly speed up calculations.

Unfortunately, such optimizations are not as easy to implement in ONI, due to the limitations of the Unity Engine. In hindsight, I believe that it would have been better if ONI had been programmed in C++. The game Factorio, which is heavily optimized, was programmed in C++ for a reason.

However, the Unity Engine does allow the game to use external DLLs (which can be programmed in C++). That way, it would still be possible to implement all of this in the Unity Engine.

I'm aware that heat exchange here made similar to average blur algorithm with kernel size of 3(i believe it called like so, when you pick pixel and its 4 neighbors(up, down, left, right)), but with bunch of additional coefficients(heat capacity, mass, heat conductivity), so basically it means in worst case(without any optimizations) it run heat exchange map_width * map_height * 4 times(for each cell, for each of it's neighbors). This is good article about optimization of blur(but for GPU shaders).

As for multi-threading all this, well since it looks similar to image processing, compute it could be done in the way GPU doing it(or even move calculations on GPU, not sure if for ONI's map size it will have some benefits): split 2d array onto smaller arrays and run in parallel computations of each of this sub arrays, then combine it in 1 big array, GPU doing it all natively but in C++ need to write all this stuff by hand. Basically you have read-only source array(current state of your map) and result array split on sub arrays, since your source is read-only there is no problem accessing it from different threads, while each thread have its own exclusive result sub array.

Link to comment
Share on other sites

Yes ONI is currently not perfect optimized. Its early access, and still in development. 

And yes, performance in development-alphas, is really horrible. 

But for stable versions, i can´t complain at all. 20 Dupes, whole world explored, surface used, and still good performance. And thats all on a i5 4460, so its not a high-end machine. 

If your computer cant handle this, maybe your rig is the problem. 

Sure, ONI will get some improvements sometime. But its still playable now.

Link to comment
Share on other sites

On 11/10/2018 at 2:35 PM, SharraShimada said:

But for stable versions, i can´t complain at all. 20 Dupes, whole world explored, surface used, and still good performance. And thats all on a i5 4460, so its not a high-end machine. 

If your computer cant handle this, maybe your rig is the problem. 

Sure, ONI will get some improvements sometime. But its still playable now.

Lol ... I even have a custom CPU cooling solution to minimize throttling in the CPU. I think I've listed my specs in the first post and the i5 6600 beats the i5 4460 by at least 15%.

I'm still crawling on the floor with that fps.

On 11/10/2018 at 3:41 PM, Oozinator said:

Share your base with FPS overlay active , or a savegame pls

Yes please! Would love to see your base and the fps you get.

Link to comment
Share on other sites

As general information, I have yesterday spent some time on a good budget value recommendation for ONI and other single core heavy games. One can compare with the Passmark CPU Single Thread Score value ( includes a link to the Passmark all-cpu-webpage ) in that post how fast the own cpu is in comparison, in terms of single core speed. Happy ONI :)

 

Link to comment
Share on other sites

51 minutes ago, ArunPrasath said:
On 11/10/2018 at 10:05 AM, SharraShimada said:

 

Lol ... I even have a custom CPU cooling solution to minimize throttling in the CPU. I think I've listed my specs in the first post and the i5 6600 beats the i5 4460 by at least 15%.

I'm still crawling on the floor with that fps.

Actually i have half the single core processing power http://cpuboss.com/cpus/Intel-Core-i5-6600-vs-Intel-Core-i3-6100U  and it was enough for all applications i had on my computer. True factorio runs a bit slow in the endgame xcom2 take a bit to load but as example surviving mars does not need much more visual studio and unity run perfectly fine. Its always oni that does crawl.

Link to comment
Share on other sites

48 minutes ago, SharraShimada said:

Small decent base, 20 Dupes, space opened, and started to build there. Its not a great FPS, but it works, even on high speed. On normal speed, its around 50fps (depends on what is current displayed). And yeah, i know, everything below 120fps is bad for some people out there. 

Ultra Settlement.sav

I have loaded your savegame. 30FPS at third speed and ~45-50 at normal.Springs a bit. Nobody of us wish that the game run with 120fps. U don't get the point. I were fine with this FPS at a real great base!

But, your base is SMALL. U haven't great areas with liquefaction, nor a great base. U have a little base in the center of the map (Startarea), some leaders over the whole map and some solar panels. That is not what we mean. We mean bases where u have 20 fps or less on NORMAL speed and 5 FPS at the third + teleporting dupes + idling + doing weird things.

 

Link to comment
Share on other sites

6 minutes ago, Oozinator said:

That "essentially" is not fair for new buyers, because end-, or even midgame is not in reach with that..

I have one i get now after removing a hog mod on turn 278 13 fps...

28 minutes ago, DustFireSky said:

Gets me 20 fps at normal speed, but it somehow looks not very demanding.

Link to comment
Share on other sites

A really good thing is that Klei lets the forum posters freely chat about their game topics and hot issues.

In the WorldOfWarships game a new premium ship is sold for something like $120,  its a tier9 ship ( tier10 is the max in the game ).

So I posted "What about some Tier11 ship for $200 ?" into a long ongoing thread with lots of user posts. Some guy replied in that thread with "I`ll buy it, take my money!". Wargaming closed the thread within 5 minutes after that with the answer "Not constructive - Thread closed" -> They didnt want to have their greed on prominent display and public discussed.

With WorldfWarhips,Crossout&EvEonline Ive spent some 5 digits on ingame purchases - Its also the 3 games where I have received ingame or forum death threats on multiple occasions. People are too time and money invested. I dont do ingame purchases anymore, its a sad path of the industry ( including loot boxes,paid ammunition,land or planet purchases, purchase of ships/vehicles/components, purchase of game time,daily login bonus etc. ).

Link to comment
Share on other sites

6 minutes ago, babba said:

A really good thing is that Klei lets the forum posters freely chat about their game topics and hot issues.

In the WorldOfWarships game a new premium ship is sold for something like $120,  its a tier9 ship ( tier10 is the max in the game ).

So I posted "What about some Tier11 ship for $200 ?" into a long ongoing thread with lots of user posts. Some guy replied in that thread with "I`ll buy it, take my money!". Wargaming closed the thread within 5 minutes after that answer as "Not constructive - Thread closed" -> They didnt want to have their greed on prominent display and public discussed.

Klei understands having a good community behind the company is valuable. We bring in valuable information at a good pace through testing. It's quite logical they don't want to put the brake on that. I personally would have liked a more direct communication with the actual developers, but I understand that would eat up their valuable time.

Link to comment
Share on other sites

On 11/12/2018 at 2:46 PM, SharraShimada said:

ultrasettlement.thumb.png.b8ed947300117d2e78cdc67490ff6143.png

 

Small decent base, 20 Dupes, space opened, and started to build there. Its not a great FPS, but it works, even on high speed. On normal speed, its around 50fps (depends on what is current displayed). And yeah, i know, everything below 120fps is bad for some people out there. 

Ultra Settlement.sav

For me, everything above 10 fps is amazing. That's how I play minecraft 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...