Factorio Forums

The talk of optimisations in recent FFF posts (eg. 148, 151), and the main loop changes (FFF 150) got me thinking. Does Factoro really need to run at 60 UPS (updates per second)?

A significant performance gain should be possible by changing the game to run at, say, 30 UPS.

To keep the game playing the same, simply speed things up:

• belts changed to move things twice as far per update
• inserters move twice as far per update
• assemblers, miners, etc process twice as much per update

There are mods that provide faster belts, inserters, assemblers, etc - so I can't see any major issues in any of this.

Of course, many players won't like the frame rate also dropping to 30 FPS, so would need to be combined with code to generate extra frames for display purposes. This was already mentioned as a possibility in FFF-150 (as a possible 144 FPS/60 UPS), so 60 FPS/30 UPS is the same kind of thing.

Ah, we already had this idea. This influences the determinism of the game (you cannot replay such a game for example). Possible: Yes. Useful: Hm.

Ah, found it:
viewtopic.php?f=6&t=19918 Why isnt there a setting for changing default UPS?

Sure, having a variable reduction in UPS would break deterministic replays and multiplayer - but I'm not suggesting that at all. Rather, a universal, global reduction for all to 30 UPS.

Yes, you couldn't load a replay from an old 60 UPS save, but (as far as I know) replays would break on most game updates anyway.

I did consider suggesting the UPS being an option on game creation, but decided against suggesting it - additional complication, no real gains.

Why would uncoupling the FPS help at all?

If you took the FPs and ran it at 120 right now you would get 2 *literally* identical frames drawn then the game would tick once then 2 more *literally* identical frames drawn. There's no advantage to rendering more FPS than UPS in Factorio.

I think the point is you might want to halve the number of FPS, not double it. The human eye struggles to notice frames over 30fps anyway unless there are big changes to the image (turning quickly in FPS games for example) and not really much happens that quickly in Factorio.

Would this not be as simple as adding another update to the game loop (two updates per frame)? It would dramatically improve performance for those with integrated graphics and could just replace the default loop if enabled. Not sure how this would affect replays as I don't know how they are stored and likewise swapping the setting on the same game but wouldn't have thought there would be big problems on either...

Rseding91 wrote:Why would uncoupling the FPS help at all?

If you took the FPs and ran it at 120 right now you would get 2 *literally* identical frames drawn then the game would tick once then 2 more *literally* identical frames drawn. There's no advantage to rendering more FPS than UPS in Factorio.

I know. However, in FFF-150 it mentions the possibility of allowing FPS higher than UPS, generating intermediate frame data so it's not identical frames.

it leaves possibility to free the FPS and UPS, so we can have for example 144 FPS/60 UPS. For example we briefly talked about the possibility of interpolating the position of the player sprite and camera, so very high framerates could make sense sometime in the future.

Personally I'd be happy with 30 FPS but I know many gamers prefer higher frame rates, hence I included this suggestion.

I think it's a solution for more than 60 fps, but correct me if i know something wrong.
If the developers makes the chance to get a maximum of 120 UPS (which you can only set at generating the map) they could devide by half everything's speed (train acceleration, factorys, belts, players, other vehicles acceleration, the flow of the time)
I'm almost sure the developers alredy had this idea, but what if they not? And in other hand, if they had this idea, i'm interested in what's the problem with this

Note:I know there can be a problem with it when you try the 120 UPS setting in a "wooden pc", but players who wants more fps, they may had the hardware to get Factorio run twice as fast as normally.

Deadly-Bagel wrote:I think the point is you might want to halve the number of FPS, not double it.

Agreed. Personally I wouldn't mind a reduction to 30 FPS, but many gamers do prefer higher frame rates

Deadly-Bagel wrote:Would this not be as simple as adding another update to the game loop (two updates per frame)?

That completely defeats the point of my suggestion, which is to reduce the CPU load of the update. Factorio isn't particularly graphics intensive, so I'm not sure even integrated graphics are a major issue - hard for me to tell as my system is far more CPU limited than GPU in this game. It's possible the multi-threaded nature of the code means multiple updates already happen if the GPU is the limiting factor though.

MPeti1 wrote:If the developers makes the chance to get a maximum of 120 UPS (which you can only set at generating the map) they could devide by half everything's speed (train acceleration, factorys, belts, players, other vehicles acceleration, the flow of the time)

That's the complete opposite of my suggestion - wouldn't optimise anything.

My PC already starts to struggle keeping 60 FPS in the mid to late game, chugging through the heavy blue science, and my current long term game (1000 rockets launched, 4 rockets/minute) now averages around 25 UPS (it's getting a bit annoying now, time to start a new game soon)

Breaking replays is the smallest of problems. They only matter to a few, and you can literally state that "warning: Changing this setting will break your replay!". So no biggie.

Being able to run the game at 30 or 20 UPS would be great for megabase builders who need to trim all the CPU cycles they can.

I thought I saw someone make the statement, "The human eye can only see 30 FPS". So, I did some Googling and found a cool article:

http://www.technologyx.com/featured/und ... 30v60-fps/

“The USAF (United States Air Force), in testing their pilots for visual response time, used a simple test to see if the pilots could distinguish small changes in light. In their experiment a picture of an aircraft was flashed on a screen in a dark room at 1/220th of a second. Pilots were consistently able to “see” the after image as well as identify the aircraft. This simple and specific situation not only proves the ability to perceive 1 image within 1/220 of a second, but the ability to interpret higher FPS.

Just posting this for the novelty factor. I thought it was interesting.

I didn't say you "could" only see 30fps, I said that unless the image changes drastically you'll struggle to notice it.

jonatkins wrote:That completely defeats the point of my suggestion, which is to reduce the CPU load of the update. Factorio isn't particularly graphics intensive, so I'm not sure even integrated graphics are a major issue - hard for me to tell as my system is far more CPU limited than GPU in this game. It's possible the multi-threaded nature of the code means multiple updates already happen if the GPU is the limiting factor though.

I don't follow (to be fair it's late and I'm tired)... CPU will be doing the same amount of processing as it still has to process 60 UPS. If your GPU isn't the problem, how will separating the FPS help?

If you wanted more FPS, shouldn't you be able to take any object that moves and draw it half way between the old and new position for that tick between two update ticks?

Deadly-Bagel wrote:

jonatkins wrote:That completely defeats the point of my suggestion, which is to reduce the CPU load of the update. Factorio isn't particularly graphics intensive, so I'm not sure even integrated graphics are a major issue - hard for me to tell as my system is far more CPU limited than GPU in this game. It's possible the multi-threaded nature of the code means multiple updates already happen if the GPU is the limiting factor though.

I don't follow (to be fair it's late and I'm tired)... CPU will be doing the same amount of processing as it still has to process 60 UPS. If your GPU isn't the problem, how will separating the FPS help?

No - the CPU will be doing far less work at 30 UPS than 60 UPS.

For example, instead of a belt moving items a distance of, say, 4 units every update, 60 updates per second, belts move items 8 units per update, at 30 updates per second. Both cases move an item 240 units in a second, but 30 UPS is half the work, (No idea what the actual position units used are in the game, but you should get the idea)

Ranakastrasz wrote:If you wanted more FPS, shouldn't you be able to take any object that moves and draw it half way between the old and new position for that tick between two update ticks?

So, now you need to keep the info about the real entity position, and it's graphical representation position. Then calculate it's position on the next step, but not make that step and instead additionally calculate the graphics position between those steps and then draw that intermediate state and only then draw the step, you've already calculated. To draw moving things you need to know, where they are moving, to draw assemblers you need to know whether they are crafting, so you'll probably need almost complete game tick already performed in order to start calculating the intermediate drawing state.

It might not work as well as you think.
Game loop and rendering is already decoupled and runs separately - it's synced only on render preparation stage.
You can see how long it takes in the debug menu - rest of render should be on separate thread that main game loop.
(Based on info from https://www.factorio.com/blog/post/fff-151)

orzelek wrote:It might not work as well as you think.
Game loop and rendering is already decoupled and runs separately - it's synced only on render preparation stage.
You can see how long it takes in the debug menu - rest of render should be on separate thread that main game loop.
(Based on info from https://www.factorio.com/blog/post/fff-151)

Earlier, didn't one of the developers say there would be no advantage in separating FPS from UPS because you would just have multiple identical frames? When he said that, my first thought was any game with a moving representation of the player would benefit from higher FPS because it would make the game seem more responsive. But if the rendering is occurring at the same time as the game updates, then you would have identical frames. Or, to put this another way:

1. Game Loop and rendering coupled - No advantage to higher FPS because the player can only move as fast as the rendering. This is what I thought the developer said.
2. Uncoupled. Player object should be able to move *faster* than the game updates.

garath wrote:

orzelek wrote:It might not work as well as you think.
Game loop and rendering is already decoupled and runs separately - it's synced only on render preparation stage.
You can see how long it takes in the debug menu - rest of render should be on separate thread that main game loop.
(Based on info from https://www.factorio.com/blog/post/fff-151)

Earlier, didn't one of the developers say there would be no advantage in separating FPS from UPS because you would just have multiple identical frames? When he said that, my first thought was any game with a moving representation of the player would benefit from higher FPS because it would make the game seem more responsive. But if the rendering is occurring at the same time as the game updates, then you would have identical frames. Or, to put this another way:

1. Game Loop and rendering coupled - No advantage to higher FPS because the player can only move as fast as the rendering. This is what I thought the developer said.
2. Uncoupled. Player object should be able to move *faster* than the game updates.

The FPS and UPS aren't coupled. FPS can run higher than UPS - there's just no reason to do so since what it will actually render is identical unless the game update has ticked again.

Can we divide the game elements into these categories?

1. Factory elements
2. Moving enemies
3. Moving player

If I understand correctly, the game currently updates the state--and thus what is rendered--for all three groups of items at the same rate that we call the Updates per Second. When the OP mentioned decoupling UPS and FPS by altering how many items are processed by the factory every update, it was my understanding he was asking for factory elements (1) to be decoupled from moving entities (2), (3).

In a Mega Factory at the end of the game, assume:

1. You have 10,000 factory elements that must be updated across the map
2. The viewport might have only 500 moving enemies
3. The viewport has only 1 player

When we ask that you decouple UPS and FPS, we are asking that the 10,000 factory elements across the entire map be updated at a different rate than the 500 moving enemies and 1 player visible in the viewport. I make the assumption that it requires substantially fewer CPU resources to process the AI and motions of the enemies and accept input from the player than it takes to perform the calculations for the entire factory.

I understand there is likely considerable work in decoupling these elements. But ultimately the development team will have to determine their goals. If we assume they want to write a game that maintains a certain frame rate for a particular factory size, then they can either find some way to reduce the CPU resources required by the Mega Factory. Or, they will need to decouple the calculations required for the moving elements in the viewport from the calculations for the factory elements across the entire map.

Edit: I assume to be fair. I should either take the enemies that are *not* visible and either group them with the factory elements calculated less frequently than the ones in the viewport or add a 4th grouping that is the enemies that aren't visible in the view port.

jonatkins wrote:No - the CPU will be doing far less work at 30 UPS than 60 UPS.

For example, instead of a belt moving items a distance of, say, 4 units every update, 60 updates per second, belts move items 8 units per update, at 30 updates per second. Both cases move an item 240 units in a second, but 30 UPS is half the work, (No idea what the actual position units used are in the game, but you should get the idea)

Oof... There are so many implications with this.

Circuit logic updates every tick so that will be seriously messed up, and what you're suggesting is essentially changing the length of a tick relative to game time. This would also affect things like solar power etc so would require a rewrite of... basically the whole game.

There would be so much additional work for the processor to synch it back in you're probably looking at -at least- 75% of the work, not half.