Optimisation suggestion - Reduce UPS, uncouple FPS

[jonatkins]

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.

Changing the length of a tick, from 1/60th to 1/30th second, is exactly what I'm suggesting. Sure, it'll touch nearly every area of the game, but in a minor way. I don't know why you think solar would be an issue. Panels produce twice as much energy per tick, days are half as many ticks long - not complex.

I'd hope (but don't know) that most things are defined in terms of real time (seconds, minutes, etc) within the code, and a compile-time constant is used for ticks per second. Change the constant, then test to see if anything breaks/changes.

I'm not suggesting that the code tries to fake it - run at 30 UPS and still make it appear to the player it's 60 UPS - that would be silly. Yes, circuit network timers would need changing, but that's pretty minor compared to the breaking changes seen in each major release. Factorio is still alpha, things change.

[Deadly-Bagel]

Yeah but if you change the length of a tick you can drastically affect certain circuit network setups and now games are no longer consistent. You won't be able to take a lot of circuit blueprints created in 60UPS game and paste them into a 30UPS game, and troubleshooting will be a pain.

[jonatkins]

I'm not suggesting that UPS be configured on a per-game basis, that would lead to complications. Rather, from (say) 0.15.0, UPS becomes 30 for everyone, and some setups from earlier versions would need changing. This isn't new. e.g. 0.13 changed train lengths and inserters (stack size changes, stack size used to/from belts, smart->filter), 0.12 changed gun turret sizes, so breaking changes in major updates are not new.

I'm not really sure what drastic problems you think this would cause with circuit networks - care to elaborate?

[Deadly-Bagel]

Any circuit network setup relying on any sort of timer would need to be tweakable to work between the two update rates, for example those working on times of day or in a belt loop or w/e. Would this also break things like how many ticks items stay on a belt or inserter? Not sure how complex some circuit setups are. This isn't a problem if everyone's game is forced on to the same update rate.

However I don't want to run at 30UPS, I'm quite happy at 60 thank you and I imagine 99% of players are behind me on that one so good luck campaigning for that.

[steinio]

30 UPS means the game runs with half the speed as now.
So this makes no sense.

Everyone with not very powerful computers know the pain with slow motion playing and wish it away.
So why should everyone get this behavior?

Greetings steinio

[Optera]

Changeable tick length can and will break complex combinator builds, but i guess XKnight will weave his black magic even with such changes.
Thinking further, a lot of mods would need to be rewritten or are simply unsalvageable since 1 tick is not a fixed time frame anymore.

[Deadly-Bagel]

30 UPS means the game runs with half the speed as now.

He's suggesting a tick then calculates double distance, power generation and consumption, etc so effectively it runs at the same speed. Ie instead of running 4 units per tick you would run 8 units half as often, so per second you still run the same speed.

It would require a lot of work, combing the entire game for anything that relies on ticks and ensuring its figures are adjusted accordingly, AND extensive testing of the whole lot. And what do we get for all that work? A lot of work for modders to do the same, half the FPS and players needing to redo any circuit setups relying on ticks, all so it runs a bit better on crappy computers.

I don't think so.

[garath]

30 UPS means the game runs with half the speed as now.

He's suggesting a tick then calculates double distance, power generation and consumption, etc so effectively it runs at the same speed. Ie instead of running 4 units per tick you would run 8 units half as often, so per second you still run the same speed.

It would require a lot of work, combing the entire game for anything that relies on ticks and ensuring its figures are adjusted accordingly, AND extensive testing of the whole lot. And what do we get for all that work? A lot of work for modders to do the same, half the FPS and players needing to redo any circuit setups relying on ticks, all so it runs a bit better on crappy computers.

I don't think so.

You raise some interesting points. It would be interesting to have better information about computer specs versus factory size. Given a "middle of the road" computer, how big a factory can you build and still maintain 60 UPS. If the developers think the average "middle of the road" computer can handle as large a factory as the majority of players will ever build, then, yeah, absolutely, why re-code the entire game just to support folks who are either:

1. Building factories significantly larger than average, or
2. Running on a computer that is FAR below average specs.

[Deadly-Bagel]

I have a laptop coming up on six years old that runs Factorio smoothly. On my largest factory I was chewing through four blue iron belts and four blue copper belts, with pretty much the entire factory active (was trying to get everything to use as much as possible for the X thousand [component] per hour achievements), and if I zoomed right out over the busiest section of the factory I had only a minor FPS drop. All graphics are set to highest quality.

Actually I did have a bit of a problem with the no solar achievement, if I had my huge array of boilers on the screen the steam was causing some FPS problems but I just disabled smoke, problem solved.

This is a 1.73GHz i7, 8GB RAM and a 1.5GB NVIDIA graphics card, not exactly high end these days. Anything running a half decent modern i5, at least 4GB RAM and a half decent video card (my business quad card at work barely runs YouTube) shouldn't have any problems on highest settings for your average game. Would you want to seriously game on anything less than this anyway?

[garath]

I have a laptop coming up on six years old that runs Factorio smoothly. On my largest factory I was chewing through four blue iron belts and four blue copper belts, with pretty much the entire factory active (was trying to get everything to use as much as possible for the X thousand [component] per hour achievements), and if I zoomed right out over the busiest section of the factory I had only a minor FPS drop. All graphics are set to highest quality.

Actually I did have a bit of a problem with the no solar achievement, if I had my huge array of boilers on the screen the steam was causing some FPS problems but I just disabled smoke, problem solved.

This is a 1.73GHz i7, 8GB RAM and a 1.5GB NVIDIA graphics card, not exactly high end these days. Anything running a half decent modern i5, at least 4GB RAM and a half decent video card (my business quad card at work barely runs YouTube) shouldn't have any problems on highest settings for your average game. Would you want to seriously game on anything less than this anyway?

Hmm....

1. It sounds like your laptop is higher than the average specs for most folks playing Factorio.
2. It sounds like your factory is on the small scale compared to many posted on the forums.
3. You just acknowledged that running on a high end gaming laptop and with a relatively small factory you had FPS problems.

Based on these three items, I think you just proved the point of this entire thread.

[ssilk]

Hm. Sorry to interrupt this really useful discussion, but instead of concentrating of such really questionable features we should suggest to optimize the game more. Like https://www.factorio.com/blog/post/fff-151

[Deadly-Bagel]

Sure, a high-end gaming laptop released over six years ago. If you went out today and bought a bog standard average i5 it would smoke my i7, it was a very early model and while it was ridiculously good at the time the architecture has dramatically improved and the relative cost has dropped. By today's standards my laptop is most definitely average and I only experienced minor FPS drops with over 100 boilers on-screen pumping out steam (true enough there may be some optimisation possibilities there but with a simple setting it ran fine) OR a zoomed-out view of my factory with well over 2,000 entities (not including thousands of belts and almost 1,500 logistics bots flying around) on-screen all working at once. Not exactly standard conditions for me and if you want to watch 6,000 tiny little animations all at once you can either drop the quality or upgrade your kit.

RAM isn't necessarily a big deal when gaming, allow 2GB for Windows to run smoothly and another 2GB for the game, 8 gig is very comfortable and 16 is unnecessary. Typically the VRAM is where bottlenecks happen and 1.5GB VRAM isn't high at all by today's standards. The modern equivalent of my laptop, something like the G752VY model has 4GB. If you go higher, there's a model with 8GB. By no means do I own a high-end gaming laptop, not today anyway.

Sure, if you use integrated graphics and you don't have a decent processor and a lot of RAM, you'll run into problems. However if you are using integrated graphics I think it is unrealistic to expect games to run smoothly on max settings.

Hm. Sorry to interrupt this really useful discussion, but instead of concentrating of such really questionable features we should suggest to optimize the game more. Like https://www.factorio.com/blog/post/fff-151

Thank you ssilk, that's what I'm getting at.

[Zeblote]

I'm not suggesting that UPS be configured on a per-game basis, that would lead to complications. Rather, from (say) 0.15.0, UPS becomes 30 for everyone, and some setups from earlier versions would need changing. This isn't new. e.g. 0.13 changed train lengths and inserters (stack size changes, stack size used to/from belts, smart->filter), 0.12 changed gun turret sizes, so breaking changes in major updates are not new.

I'm not really sure what drastic problems you think this would cause with circuit networks - care to elaborate?

Nonsense, you can't make the game worse for everyone just so it runs on some crap computer. If you really want this to be a thing, it has to be optional.

[garath]

Hm. Sorry to interrupt this really useful discussion, but instead of concentrating of such really questionable features we should suggest to optimize the game more. Like https://www.factorio.com/blog/post/fff-151

This is a thread about optimizing the game. (See the thread title.) I'm surprised you would first call this thread "questionable" and then suggest we optimize the game more.

I would expect you to say instead, "The developers *already* acknowledge the need to optimize the game and are approaching it from a different direction."

[ssilk]

This is a thread about optimizing the game. (See the thread title.) I'm surprised you would first call this thread "questionable" and then suggest we optimize the game more.

Sorry, "optimizing software" means for me something different, not this subject. That is more "Speed things up by slowing down others".

I would expect you to say instead, "The developers *already* acknowledge the need to optimize the game and are approaching it from a different direction."

Sounds much more diplomatic.

The truth is: "The developers LOVE to optimize the game, but that is a really hard and expensive struggle."

[jonatkins]

For anyone watching this thread and like the idea of 30 UPS/FPS for large factories, this mod - viewtopic.php?f=91&t=50281 - despite the thread title, can be configured that way.

It's not perfect - any displayed values based on time (e.g. power in MW) are off as the game assumes 60 UPS still. And there's currently a bug with nuclear reactors requiring them to be removed/replaced before they consume fuel + generate heat at the modified rates on an existing game.

[SyncViews]

My understanding of whats been asked many times before is for interolation, not duplicate frames, but not sure its really been understood. Reducing FPS like in that mod makse the expierence less smooth.

e.g. a simple solution games may use looks like this. The maths means moving objects are not duplicated, and could even deal with say animations to an extent (e.g. 30UPS but 60FPS animation, or an assembler with speed modules 30UPS but 144FPS animation).

Code: Select all

//dt is a value from 0 to 1. Each update step is effectively "in the future", FPS may be more or higher, object positions are always smoother, 20FPS, 30FPS, 55FPS, 140FPS, whatever
graphics.camera.position = player.prev_pos + (player.pos - player.prev_pos) * dt;

void Object::update() // **this is still fixed UPS and deterministic, no code change except to copy state**
{
    prev_positon = position;
    ... do normal update...
}
void SpriteObject::render(float dt)
{
    sprite.draw(prev_position + (position - prev_position) * dt);
}

The only real loss / complication is things that update on a high frequency, e.g. circuits become limited to say 30Hz rather than 60Hz, and assemblers are capped at 30 outputs per second.

[Rseding91]

My understanding of whats been asked many times before is for interolation, not duplicate frames, but not sure its really been understood. Reducing FPS like in that mod makse the expierence less smooth.

e.g. a simple solution games may use looks like this. The maths means moving objects are not duplicated, and could even deal with say animations to an extent (e.g. 30UPS but 60FPS animation, or an assembler with speed modules 30UPS but 144FPS animation).

Code: Select all

//dt is a value from 0 to 1. Each update step is effectively "in the future", FPS may be more or higher, object positions are always smoother, 20FPS, 30FPS, 55FPS, 140FPS, whatever
graphics.camera.position = player.prev_pos + (player.pos - player.prev_pos) * dt;

void Object::update() // **this is still fixed UPS and deterministic, no code change except to copy state**
{
    prev_positon = position;
    ... do normal update...
}
void SpriteObject::render(float dt)
{
    sprite.draw(prev_position + (position - prev_position) * dt);
}

That doesn't work in something like Factorio. The vast majority of things in the game don't "move" in the typical FPS/RTS sense. They have animation indexes and animation speeds which vary wildly between each frame. Additionally storing all of this information twice would increase RAM usage, slow the simulation speed down from cache misses while providing a poor visual experience.

[jonatkins]

The vast majority of things in the game don't "move" in the typical FPS/RTS sense. They have animation indexes and animation speeds which vary wildly between each frame. Additionally storing all of this information twice would increase RAM usage, slow the simulation speed down from cache misses while providing a poor visual experience.

So what was meant back in FFF-150, where it was said:

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.

This is why I suggested allowing FPS higher than UPS - as it's something you were already considering.

Personally, I'm pretty happy with 30FPS. I do notice the low frame rate on a few things (e.g. fast moving logistics bots), but it's worth it for the major performance improvements in large bases. The GTTS mod (https://mods.factorio.com/mods/Zanthra/GTTS) shows that it's lkargely possible in the existing framework so it shouldn't be much more work to implement this in the core game so displayed values are also correct, A game creation time option would be nice, and even better if it could be changed on existing saves once things get too slow. Restarting factorio to change this rate isn't ideal (as is needed with the mod), but would still be better than no option at all.

[SyncViews]

That doesn't work in something like Factorio. The vast majority of things in the game don't "move" in the typical FPS/RTS sense.
They have animation indexes and animation speeds which vary wildly between each frame. Additionally storing all of this information twice would increase RAM usage, slow the simulation speed down from cache misses while providing a poor visual experience.

hmm, thats still really not what I am saying. Im saying more that you run the UPS at say 30 (60 -> 30, major update performance win and more than a couple bytes memory copy per moving/animated object) but keep the FPS target 60 (as far as animation is concerned). Allthough notably the game already does have variable speed animations anyway for some things (assembling machines and steam engines).

And, every except some UI elements do move in Factorio. Movement is relative, the player moves the camera/screen, and every object is the scene is moved on screen. So even static objects gain from interpolation of the actual camera position when a player moves around.

You can also interpolate animation frames if the animation is drawn at a different speed to UPS

As for memory, "Additionally storing all of this information twice would increase RAM usage",You do not store the entire object twice, most of the object state is either not rendered or interpolation would have little to no benefit.
Static objects need no change (they cant move anyway, are not animated, etc. they benefit indirectly from the camera interpolation), stationary animated ones like belts just need a few bytes to make the animation smooth, and moving ones like biters, bots, projectiles, etc, need a dozen bytes for animation and position.



EDIT: So I mean like in this very simple JavaScript I just wrote. The red boxes both appear smooth to the user, but one is only 20UPS. A 20FPS moving object as you can see just doesnt look very good. The desync is because I didnt do all the physics maths for my "bounce", so since I am still saying all clients in the MP game would use the same UPS (just a lower one), it doesnt need to be perfect (and indeed the 60UPS one is not perfect, just a little more "accurate").
https://codepen.io/anon/pen/gxaBxR

Being 1D, this requires my interpolated box to have exactly 1 extra property (this.prevX), there are of course others, but still only a small fraction, moving objects have x, y. animated ones have an animation frame index. Most other stuff doesnt apply (e.g. no point trying to interpolate item stack sizes / inventories, that would just give the GUI wired fractional sizes that could never exist). Vehicles could maybe have a prevRotation, but as they are not 3D models, would require a very fast rotation to be noticeable.