Factorio Forums

With high frequency monitors more and more common these days, I feel that the 60hz animation rate for this game is a real limitation given how much smoother map scrolling at 120+hz is. To that end I am thinking of making some effort to make a mod that goes through all the objects in the game and reduces their speed by 50%, and then doubling the game speed to bring the UPS and draw rate to 120hz and the speed back to normal.

As for the speeds that would need to be changed (** added from comments below, thanks!)(working):

* Character move speed (and other mobs)
* Crafting speeds
* Power consumption and power production
* Inserter speeds
* Belt speeds
* Fluid production rates
* Day length
* Animation speeds
* Vehicle acceleration and top speeds
* Pollution production/spread/absorption rates
** Evolution Factor
** Repair Rate
** Weapon DoT
** Regeneration and Delay

Things that may not be possible to change well:

* Circuit network speeds
* Fluid flow speeds
** Fire damage and spread rate
** Train Schedule wait times

What do folks think of this? Also are there other speeds of concern that I may be missing?

Evo factor

Fire spread
Projectile speed.
Repair rate
Weapon Dot dps
Unit regeneration and delay

It means: no multiplayer with script-mods. 0,008(3) seconds is to few for giant fabrics or mods with complicated code.

darkfrei wrote:It means: no multiplayer with script-mods. 0,008(3) seconds is to few for giant fabrics or mods with complicated code.

Not entirely. Some mods have tick rate configs, and split work over multiple ticks. Plus if you are able to run the game at 2x speed you can probably handle some faster script anyway.

Ranakastrasz wrote:

darkfrei wrote:It means: no multiplayer with script-mods. 0,008(3) seconds is to few for giant fabrics or mods with complicated code.

Not entirely. Some mods have tick rate configs, and split work over multiple ticks. Plus if you are able to run the game at 2x speed you can probably handle some faster script anyway.

Even if you can. Factorio MP works by having all clients execute the same code at the same time or it desyncs. This means any MP game can only run as fast as it's slowest member.

Another factor using ticks that isn't obvious are train schedules.

For modders also important, a variable time scales would need to be passed through the API so we know 1 tick is no longer 1/60s but perhaps 1/120s.

I am not concerned with multiplayer at first, and if it is not multiplayer compatible, so be it. Perhaps with popularity, the Factorio Devs would be willing to implement such a time scale on the back end, or even just unlink the UPS from FPS and allow smoother panning of the map and other character motion on high frame rate displays.

As for performance, this will always be a concern, but as time goes on, processors will not get slower, and Factorio will probably become more optimized. Compatibility with other mods is somewhat of a concern, but knowing that there are more tics per second, and that mod events may happen twice as often you may be able to prepare for them (this is assuming I can make code that scans and changes all of the speed values for modded items too).

Also I use 120hz as an example here, but I hope that I can make this generic enough that it's simply an easily adjustable multiplier so that 120, 144, 165, 200, 240, 288 etc all work fine as well, although the higher rates are likely to have substantial performance problems even in small factories on current hardware.

From previous discussions.... This is beyond the scope of what mods are capable of changing. The game is written on a 60ups model, and although it is possible to change it to a 120Hz refresh rate, it would be pointless, because frame 2 would be given the same information as frame 1, no change, and therefore the 2 frames would look identical.

Although there are in theory a few solutions to this... the base 60ups hardcoding means any attempts to change 60Hz would need assistance from the development team.

The key point against this though is if you update the game content twice as often, the entire game needs to be processed twice as often. and as some performance tests have shown, the memory throughput pipeline is the bottleneck here, bigger, faster, more core processors aren't going to fix this.

bobingabout wrote:From previous discussions.... This is beyond the scope of what mods are capable of changing. The game is written on a 60ups model, and although it is possible to change it to a 120Hz refresh rate, it would be pointless, because frame 2 would be given the same information as frame 1, no change, and therefore the 2 frames would look identical.

Although there are in theory a few solutions to this... the base 60ups hardcoding means any attempts to change 60Hz would need assistance from the development team.

The key point against this though is if you update the game content twice as often, the entire game needs to be processed twice as often. and as some performance tests have shown, the memory throughput pipeline is the bottleneck here, bigger, faster, more core processors aren't going to fix this.

Using /c game.speed = 2 it draws at 120fps and updates at 120ups, each frame is drawn with different data. The issue of course is that everything goes twice as fast, which is something mods can fix by reducing those speeds by 1/2.

This is an example I just produced from 120fps recording (with my mod adjusting movements speeds and firing rates), slowed down to 1/20 so played back at 6fps. You can see character movement and background motion is updated every frame, which means less strobing and sharper smooth pursuits.

https://www.youtube.com/watch?v=3DHegVA ... e=youtu.be

As for performance, I fully appreciate that, whether eDRAM placed on the CPU package and other developments like that counter the memory usage, I don't know, but I am willing to spend my time to make the mod even so. I think that performance is a consideration, but should not prevent people from having options.

Another thing to note is that only a limited group of people will benefit from this, given that 60hz displays are still the norm, and I don't see that changing even if high refresh rate displays become a larger minority.

PS: Do you or someone else know how "spawning_time_modifier" works? I am thinking that as a modifier it should be left alone, since it will modify a value I should edit on the spawner, but if it's something else, let me know.

Alright, here is an early version of the mod if anyone wants to see the progress so far. You need to manually adjust your crafting speed with "/c game.player.character.character_crafting_speed_modifier = -0.5" although this may override crafting speed modifications from other mods, and you need to manually set the game speed with "/c game.speed = 2".

I need to rethink how I parse through some of the prototypes, as some of the speed variables are two or three layers deep, and the exceptions to the exceptions to the exceptions are piling up. I also need to go through and play with the various forms of animation, animations, and pictures that have animation speeds, or are arrays of objects that have animation speeds, and figure out where I need to add a new animation speed variable, and where I don't.

Still I loaded this into my existing Angel's + Bob's + Factorissimo game, and it seems to be working quite well so far, and since everything but the player crafting speed modification is based on the prototypes, it is easy to turn the mod on and off.

Before I start looking at the mod portal and how to add it there, I want to get the time scale into the mod options page, and do some checks and print some useful information if the game speed or the player crafting speed is not correct, or automatically correct them if I can.

The games has a FPS and an UPS. Do you really need to change the UPS to get "smoother" scrolling? Seems like you only want to increase the FPS.

And you want an FPS > UPS in your case. It should be relatively easy to have animations with multiple frames per game tick. So when the game decides an assembler is working this tick the screen will show 2 frames of animation. Then the next tick happens and the game decides if the assembler stops or keeps running.
Also when there is a brownout and the assembler is running at 50% speed this would drop to 1 frame of animation for every 2 frames drawn. Obviously this should support any ratio between FPS and UPS, not just plain 2:1. This would make assemblers with 38% power look good too.

Similar for belts. You would interpolate the item positions between ticks. Which idealy means you have to look ahead one tick to see if an item stops moving or not.

mrvn wrote:The games has a FPS and an UPS. Do you really need to change the UPS to get "smoother" scrolling?

Yes you do, because

The game is written on a 60ups model, and although it is possible to change it to a 120Hz refresh rate, it would be pointless, because frame 2 would be given the same information as frame 1, no change, and therefore the 2 frames would look identical.

In theory the Factorio devs could change the way Factorio is coded to decouple FPS from UPS by adding interpolation between frames, but

1) It would complicate the code base, and probably make Factorio run a bit slower, to handle an exceptional case rather than focus on the common case (most people don't play at 120fps, and Factorio is optimized first and foremost to be performant for megabases at 60fps)
2) it would add a small amount of visual latency to the game - after all, to interpolate between the current frame and the next frame, you have to know what happens in the next frame, which means by the time you start interpolating towards it, it has already happened - without interpolation, you would already be displaying it. So this adds 0.5-1 (60fps) frame of latency. Doesn't sound like much, but it means that you're making a sacrifice.

Patashu wrote:

mrvn wrote:The games has a FPS and an UPS. Do you really need to change the UPS to get "smoother" scrolling?

Yes you do, because

The game is written on a 60ups model, and although it is possible to change it to a 120Hz refresh rate, it would be pointless, because frame 2 would be given the same information as frame 1, no change, and therefore the 2 frames would look identical.

In theory the Factorio devs could change the way Factorio is coded to decouple FPS from UPS by adding interpolation between frames, but

1) It would complicate the code base, and probably make Factorio run a bit slower, to handle an exceptional case rather than focus on the common case (most people don't play at 120fps, and Factorio is optimized first and foremost to be performant for megabases at 60fps)
2) it would add a small amount of visual latency to the game - after all, to interpolate between the current frame and the next frame, you have to know what happens in the next frame, which means by the time you start interpolating towards it, it has already happened - without interpolation, you would already be displaying it. So this adds 0.5-1 (60fps) frame of latency. Doesn't sound like much, but it means that you're making a sacrifice.

1) Some interpolation should already be in there since the FPS and UPS are not required to be an integer ratio. At least I've seen them change freely and not in jumps of 1:1, 1:2, 1:3, ... Going the other way and doing 2:1 should not add overhead to the game.

2) There is very little that can't be predicted one tick in advance. You could do it speculative and then sometimes in the rare case that you assumed wrong you get a very minor visual glitch. For example a belt controlled by a gate and the player approaches. Will the player continue to move, the gate trigger and the belt stop or will the player stop, the gate not trigger and the belt continue to move. I would assume the player keeps on moving. But if the player releases the forward key just between ticks, just at the detection boundary of the gate, then that would be wrong. For one frame the belt would be shown as stopped and then it would jump and be shown as moving. I doubt you would notice unless you capture a video and play it slow.

mrvn wrote:

Patashu wrote:

mrvn wrote:The games has a FPS and an UPS. Do you really need to change the UPS to get "smoother" scrolling?

Yes you do, because

The game is written on a 60ups model, and although it is possible to change it to a 120Hz refresh rate, it would be pointless, because frame 2 would be given the same information as frame 1, no change, and therefore the 2 frames would look identical.

In theory the Factorio devs could change the way Factorio is coded to decouple FPS from UPS by adding interpolation between frames, but

1) It would complicate the code base, and probably make Factorio run a bit slower, to handle an exceptional case rather than focus on the common case (most people don't play at 120fps, and Factorio is optimized first and foremost to be performant for megabases at 60fps)
2) it would add a small amount of visual latency to the game - after all, to interpolate between the current frame and the next frame, you have to know what happens in the next frame, which means by the time you start interpolating towards it, it has already happened - without interpolation, you would already be displaying it. So this adds 0.5-1 (60fps) frame of latency. Doesn't sound like much, but it means that you're making a sacrifice.

1) Some interpolation should already be in there since the FPS and UPS are not required to be an integer ratio. At least I've seen them change freely and not in jumps of 1:1, 1:2, 1:3, ... Going the other way and doing 2:1 should not add overhead to the game.

2) There is very little that can't be predicted one tick in advance. You could do it speculative and then sometimes in the rare case that you assumed wrong you get a very minor visual glitch. For example a belt controlled by a gate and the player approaches. Will the player continue to move, the gate trigger and the belt stop or will the player stop, the gate not trigger and the belt continue to move. I would assume the player keeps on moving. But if the player releases the forward key just between ticks, just at the detection boundary of the gate, then that would be wrong. For one frame the belt would be shown as stopped and then it would jump and be shown as moving. I doubt you would notice unless you capture a video and play it slow.

Heh. Its not like the player isn't already doing that. If you have a script that uses the player's position, it uses the server-side position, which does not correspond to that of the player. So it wouldn't be anything new.

The Global Tick Time Scale mod is up on the mod portal and has a thread under general mods.

viewtopic.php?f=144&t=50281