Above 60 fps (120 or 144).

[Hakisak]

Hello,

My suggestion:
The ability to run the game at 120 or 144fps to match more high-end monitor's refresh rate.

why?
Because 144 master race? some people would like to use their monitors full potential and this game will look much more smooth when moving the player around.

I know about the game speed command but playing at double speed is unpractical.

-your game is exactly my type and i love it <3
keep up the good work!

[bobingabout]

The issues with this are have been explained before.

The very core of the game depends on a per tick calculation, everything from how far something has moved, to how much power was generated.

Therefore, even if you had 120fps, every first and second frame would be identical, resulting in 60 unique fps.

The solution to your issue is to calculate ticks twice as often, as with the game speed command.

The problem there is, you would then need to half the progress done with each tick to slow the game back down to normal speed... this is the hard part, the variable tick length, the entire game engine was built around a constant tick length, so changing it would be... challenging at best.

[SyncViews]

Variable tick length would break the multiplayer model, so its really not going to happen, and is not needed. Generally you want to avoid this anyway, variable time step screws with physics simulations, and makes every single piece of logic more complex. Rather you can interpolate object positions for rendering with a fixed update rate (e.g. "render_position = prev_position + (position - prev_position) * fractional_step"), but the game doesn't do that, and it doesn't work with pre-rendered or hand drawn animations (not a 3D game) so would only be a partial solution even if the devs did it.


And I still dont really get the need? This is not a fast paced fps where lacking good motion blur there is some difference between 30fps and 120+fps. I don't see the masses complaining about TV/film (24fps) or 2D animated video (often 12fps or less).


Maybe they should just change the game to double or even triple the frames so that the in and out of game FPS counter says 144fps and see how many people really notice...

[Hakisak]

The issues with this are have been explained before.

The very core of the game depends on a per tick calculation, everything from how far something has moved, to how much power was generated.

Therefore, even if you had 120fps, every first and second frame would be identical, resulting in 60 unique fps.

The solution to your issue is to calculate ticks twice as often, as with the game speed command.

The problem there is, you would then need to half the progress done with each tick to slow the game back down to normal speed... this is the hard part, the variable tick length, the entire game engine was built around a constant tick length, so changing it would be... challenging at best.

ah I see... its one of those games.
Do you think it would be possible to keep all the mechanics at its 60fps operational speed, but somehow half the characters(camera) movement speed and then double its operational speed. ergh, that sounds like it wont work.
we dont have to have all the mechanics(smoke,belt-speed, etc) to work at 120/144fps, do you think its possible just to have the panning camera movements to work at 120/144fps? or is it all tied together that tight?
-thanks

[SyncViews]

Camera position is the same equation I showed as for object position, for what value it adds when its only panning. Its the same thing most 3D games do, since like I said, an actual variable step simulation is normally a bad thing

[bobucles]

Even if you wanted the game to force out more frame output, the visual display is a mixture of sprite art and 3d models. It is extremely jarring to have these two things run at independent frame rates. I've seen it plenty of times growing up, and it isn't pretty.

[HL65536]

TL;DR

unlock fps

What ?

Enable a smooth experience with non-60Hz monitors by allowing more than 60fps (requires at least some decoupling of framerate from logic update ticks)
I alredy suggested this a while ago, now with upcoming graphics engine changes I thought it would be a good time for this change.
I and many others with non-60Hz displays want render extrapolation with unlocked max framerate.

Why ?

Most other games (including my own) already have it, a very basic feature that Factorio is lacking.
It is just a much smoother experience when gaming on a non-60Hz screen which are increasingly popular now, so it is time to support them as 1.0 is on the horizon.

How ?

I heard that currently a graphics frame just takes positions from last game update and draws it that way, so 120fps would mean 2 frames would look exactly the same -> 60fps limit makes sense. As the game already allows framerates below update rate, I assume there is already some way for the graphics to work on data that is stored in such a way that game update can run in parallel without changing the data that the graphics reads from. This makes the change easy.
For unlocked framerate positions need to be extrapolated into the future (interpolation of the past will not work very well!).

1st step is very easy: camera
the most influential for the smoothness feeling is the camera, it is hopefully just one class that needs the following change:

cameraPositionToDraw = camPositionOfLastGameUpdate + timeSinceUpdate*camVelocityOfLastGameUpdate

if the velocity does not exist, just save the position of the update before and use it to calculate the velocity.

2nd step would be to apply all this to all other entities that move. If there is a base class for all of that it should also be very easy.

3rd step would be to apply this to animations so even super-speed-beaconed assembler animations look smooth

I would even do this myself if I had access to the code.

[Rseding91]

It sounds like a nice idea but it simply doesn't work in Factorios world. You can't extrapolate an entity position based off it's previous movement without having a complete copy of that thing which means running the entire simulation twice (or more). Additionally the *vast* majority of entities don't move as in physical location but do move in animation state/rotation.

Things like:

• inserters move based off available energy and what item on a belt they're going after
• Trains drive on rails unless they're slowing/accelerating for signals/out of fuel
• Cars depend on how you drive them/what you hit
• Items on belts depend on every other item on the belt/if an inserter grabbed something/put something onto the belt/circuit logic
• Player movement changing based off input/equipment grid exo-legs/energy/what they ran into
• Assembling machine animation depending on if it's crafting/available energy

You simply can't extrapolate what it's going to look like with any degree of accuracy - even if we managed to make *something* work everything would look like it was constantly rubberbanding between frames and would have a massive memory overhead to track all of this extra data each frame.

Currently we attempt this kind of simulation with the player character entity and walking and it *mostly* works but you see the failures all over as you play with higher and higher latency and adds a ton of overhead and code duplication. The way the character movement works in the latency simulation is we run *just* the character simulation ahead of the normal simulation - copying what the simulation would normally do with all of the overhead plus some.

[posila]

I would like to try to do camera interpolation for high framerate displays, but that's about it.

Doing rest would take too much time, which I would rather invest into making sure we can actually keep steady 60 fps

What is your game?

[Itemfinder]

I would like to try to do camera interpolation for high framerate displays, but that's about it.

Smoother panning would be a huge plus.

[coppercoil]

You simply can't extrapolate what it's going to look like with any degree of accuracy

What if we assume: "if something is moving, then it very likely will continue to move/rotate in the same direction"? Once we have movement vector for "now", we also have prediction for now*1.5. We don't need 100% accuracy, do we?

[Itemfinder]

I think, the render speed could be doubled. 120fps is plenty, and wouldn't make tick-locked (all?) entities stutter, just update once every 2 frames. Slowing to 50 UPS would be reduce fps to 100, etc.

[Zanthra]

Try my GTTS mod which I wrote to provide more than 60 FPS: https://mods.factorio.com/mod/GTTS/downloads

Install, then go into mod options and set the target UPS to your desired value. I would recommend 120, 160, or 240 depending on your monitors refresh rate, other values will work, but objects on belts will be slower than they should be due to them moving only a multiple of 1/256 of a tile per update (all target UPS with exact belt positions are listed in the readme).

[Itemfinder]

It doesn't feel right. Details like time played, and the delay for drop multiple item to drop more when pressing Z, aren't corrected. Panning in creative stutters at 160fps where it doesn't at 80, ignoring the blur. Thanks, I'd rather wait for a vanilla solution.

[Sopel]

Smoother camera movement and moving items when in hand (and guis generally) would be enough.
I always play creative with 144 ups just because it's so much better on my monitor. For legit playthroughs, not so much choice sadly.

[MsWolphie]

I would like to try to do camera interpolation for high framerate displays, but that's about it.

I know it's a bit of a necro, but this is probably what most people wants with unlocked framerates, as "unsmooth" camera movements are the most obvious thing noticeable. The rest of the world can stay at 60ups without any problem I think.

[redstonerti]

I would like to try to do camera interpolation for high framerate displays, but that's about it.

Doing rest would take too much time, which I would rather invest into making sure we can actually keep steady 60 fps

What is your game?

So, has there been a substantial enough increase in the percentage of gamers with high refresh rate displays to make it worthwhile yet or do we have to wait more? A lot of newer displays are getting 120hz displays, even phones, so i would expect that this feature is needed more and more as the years pass

[boskid]

So, has there been a substantial enough increase in the percentage of gamers with high refresh rate displays to make it worthwhile yet or do we have to wait more? A lot of newer displays are getting 120hz displays, even phones, so i would expect that this feature is needed more and more as the years pass

I have no idea what would an increase be required for. It is simply not going to happen. Allowing to have more FPS than UPS would be one of 2 things: A/ one game state would be rendered multiple times, which is pointless as literally nothing changed between those 2 frames, or B/ there would be some extrapolation happening allowing one game state to render slightly differently as if half of a tick has passed. There is not many ways this could be done to not introduce artifacts, like if a train could move half of its speed passing a rail signal not knowing it will hard-stop before the signal anyway, or if an item on a belt would be moving not knowing how much it can even move (main cases would be when a blue belt would feed yellow belt causing items on blue belt to move slower). Any method that would try to do a perfect extrapolation would have to literally do an update saying it is "fraction of a tick" update, which would be a nightmare due to determinism in case of an MP game where a series of fractional tick updates would be required to give the same output as a single full update because other players in MP game could be running at 60UPS/FPS. To not get into madness due to fractional tick updates but still get the extrapolation it would require to have a full game state copy every tick which is just insane amount of work completly not feasible in any shape. So the only way it could be done is by means of having fractional tick drawing which we are not interested in due to possible artifacts when the extrapolated state would be not accurate or would need extra data being held and updated (performance penalty) just so during the drawing an accurate extrapolation could be done.
Most of the drawing is drawing sprites and if there are no sprites in between one exact sprite would be selected, either the previous one or the next one. To get smooth 120FPS all the animations would have to be re-rendered with twice as many frames causing extra VRAM usage.

In order for this to be feasible - to get 120FPS, it would also require updates to happen at 120UPS. This would be possible if there would be some utility constant which would say how many ticks are expected in a game second to properly scale everything but that would also mean a lot of prototype constants which were defined in terms of ticks would need to be rescaled in order to accurately describe timmings for the new ticks/second condition.

Just forget about this. It is not going to happen. With some shooters/other games where MP determinism is not important or where entire game state fits in a single network packet and it can be easily extrapolated it may be possible, but Factorio just does not meet any conditions to reasonably have more FPS than UPS due to the game state size and cost of doing extrapolation.

[redstonerti]

So, has there been a substantial enough increase in the percentage of gamers with high refresh rate displays to make it worthwhile yet or do we have to wait more? A lot of newer displays are getting 120hz displays, even phones, so i would expect that this feature is needed more and more as the years pass

I have no idea what would an increase be required for. It is simply not going to happen. Allowing to have more FPS than UPS would be one of 2 things: A/ one game state would be rendered multiple times, which is pointless as literally nothing changed between those 2 frames, or B/ there would be some extrapolation happening allowing one game state to render slightly differently as if half of a tick has passed. There is not many ways this could be done to not introduce artifacts, like if a train could move half of its speed passing a rail signal not knowing it will hard-stop before the signal anyway, or if an item on a belt would be moving not knowing how much it can even move (main cases would be when a blue belt would feed yellow belt causing items on blue belt to move slower). Any method that would try to do a perfect extrapolation would have to literally do an update saying it is "fraction of a tick" update, which would be a nightmare due to determinism in case of an MP game where a series of fractional tick updates would be required to give the same output as a single full update because other players in MP game could be running at 60UPS/FPS. To not get into madness due to fractional tick updates but still get the extrapolation it would require to have a full game state copy every tick which is just insane amount of work completly not feasible in any shape. So the only way it could be done is by means of having fractional tick drawing which we are not interested in due to possible artifacts when the extrapolated state would be not accurate or would need extra data being held and updated (performance penalty) just so during the drawing an accurate extrapolation could be done.
Most of the drawing is drawing sprites and if there are no sprites in between one exact sprite would be selected, either the previous one or the next one. To get smooth 120FPS all the animations would have to be re-rendered with twice as many frames causing extra VRAM usage.

In order for this to be feasible - to get 120FPS, it would also require updates to happen at 120UPS. This would be possible if there would be some utility constant which would say how many ticks are expected in a game second to properly scale everything but that would also mean a lot of prototype constants which were defined in terms of ticks would need to be rescaled in order to accurately describe timmings for the new ticks/second condition.

Just forget about this. It is not going to happen. With some shooters/other games where MP determinism is not important or where entire game state fits in a single network packet and it can be easily extrapolated it may be possible, but Factorio just does not meet any conditions to reasonably have more FPS than UPS due to the game state size and cost of doing extrapolation.

I think you might have misunderstood my question. The reason i quoted the camera interpolation reply is because that is what i am talking about. Literally only that. I don't need the whole game to run at 120fps or 120ups.
In fact, even if that happened it wouldn't be ideal as my display is not 120hz, it's 240hz and there are many refresh rates in between. All i was asking was if camera interpolation would be considered in order to make it easier to identify items while in motion and to reduce motion sickness. Nothing else. And just to clarify, i don't mind if nothing has changed in that extra frame other than the position of the camera. The author of that reply said that it was possibly feasible but not sure if it was worth the time so i was just asking to see if anything changed between 2018 and 2021 that would make it worth the dev's time.

Thank you for taking the time to respond.

[Tertius]

[...] and to reduce motion sickness.

Is motion sickness with Factorio really an issue for you? Just curious and asking if this is a real thing for you with Factorio. I know motion sickness is very subjective and every case is different, however although I am very sensitive to motion sickness myself and cannot play quite some 3D games, I never felt the slightest issue with Factorio. The isometric view is commonly perceived the most convenient and painless mode possible for motion sickness-troubled people.

Also there is no difference (for me) above 60 fps: if I feel motion sickness with 60 fps, I still feel it with 144 fps (my current monitor). My motion sickness increases with fps rates below 50 fps, but the main trigger is screen tearing, and the change of the perspective, which is never happening with isometric views.