Factorio Forums

The update from the quite quiet times: https://www.factorio.com/blog/post/fff-70

I think the main difference between RTC and Factorio is, that in Factorio calculations needs to be deterministic, but in RTC not; an RTC can normally stop at any point, but for Factorio this would kill the determinism.

Wait, you can say "The calculations needs to be deterministic at some point in future, but not for every frame..."? Because that would enable you to stop calculation at any point and continue later.

Keep up the good work. I've been ever expanding my first complete factory for the eventual update to the end game. Primary because it is more fun than the extremely early game to me!

Anyway, I'm approaching 1 million stockpiled Iron Ore, and my railroads keep bringing more every few seconds. Copper isn't nearly as stocked, only about 60k, but I have 73k copper wires for some reason. Time to start expanding the smelters I guess. Can't wait for 0.12!
Thanks

I wait with baited breath.

No really, I'm nervous for this end game content....

Performance issues are a real problem. They are hard to solve, solutions gives little better performance, but there're always more issues to solve. One possibility is to allow game to be 1 frame late in certain cases, although this doesn't sound like a good idea. Maybe improving the sleep of not used entities, like machines? Don't know the in-depth cases of those, but in a really big factory, they may have a big impact. Much of the optmizations I can think of removes the possibility of modded entities =\

Interesting read, always fun and frustrating to work on the ever elusive better performance. There are definitely some issues with performance in the game and I believe they are going to get worse as the program more advanced and more features are added. Going to be some tough work for your team to work it all out. Hopefully you are doing as much as you can in decoupling the game "state" from the display state as much as you can and doing things of skipping frame updates where you can on some items etc.

Keep up the great work and looking forward to watching this game progress.

Issue is that when UPS drops before FPS, even movement gets laggy. Hard to overcome this.

There are two factors a developper can not really control : The player's hardware, and the size of the factory (plus the zoom level the player can achieve, ok for three ). You have to make some hypothesis, and put some limites in the form of :
- With that hardware
- With that many objects in the factory
- With that many things to be rendered

I guarantee I can do all operations needed to compute, render everything in that many ms, guaranteeing this many FPS and UPS.

If you want to improve any aspect of this equation (in fact it's more of an inegality), without degrading FPS/UPS, you have to raise the minimum requirements, or optimize the way the factory is computed (multithreading, better algorithms, ...) and/or rendered.

But it will never be possible to guarantee a minimum performance for infinitely big factory. All the trick then is "how should the game react if hardware does not allow the computation and rendering of a frame during a frame's lapse ?".

Well I really like that kind of questions, maybe because I'm a former RT dev myself . RT dev is not about being fast, or simultaneous, but about always being on time, whatever the unfavorable conditions.

It is great that you are working on smooth fps - but I find it more urgent that you work on the GUI.

At the moment it is hard to play in low resolutions (things glitch out of screen) or to play in very high resolutions (things are too small).

The only thing that holds me back from making a Let's Play series is, that I want to play it in high resolutions but also want to be sure people who don't watch the video in fullscreen mode or in a low resolution can still see the icons well enough to know what it is.

I would be very happy if you could focus on this problem in the next few weeks.

-Nic

I gotta say though, the game runs fantastic, even on my old laptop. I'm pretty sure Factorio was the only game I could get consistent 60 on. Making it run better is great, but I think prioritizing other things is more important.

Koub wrote:RT dev is not about being fast, or simultaneous, but about always being on time, whatever the unfavorable conditions.

Exactly. This game could never achieve true Real-Time, because the OS is doing the scheduling for CPU time and you can't (and probably shouldn't) make Factorio get a high enough priority that you can guarantee any tasks to finish before a certain tick/time. There's something called WCET (Worst Case Execution Time), and with all the other possible processes/threads etc. running on an OS, this time would be unrealistically high.
Also, like Koub said, you don't even know the end user hardware anyway, though that could be specified with some minimum requirements.

It can help some within the Factorio process though, and prioritize some important tasks over others, and since there isn't really any danger for life/property here, true Real-Time isn't that important anyway so I definitely think you can learn something useful from it

so much juicy high performance code.
I wish I could do an internship at your place to learn more about such a speed oriented code.

Btw, how often do you use pointers? I heared pointers eat performance : http://gameprogrammingpatterns.com/data-locality.html

Tankh wrote: Exactly. This game could never achieve true Real-Time, because the OS is doing the scheduling for CPU time and you can't (and probably shouldn't) make Factorio get a high enough priority that you can guarantee any tasks to finish before a certain tick/time.

This is not really true. An application has many possibilities to get CPU time, when it really needs it. There is a wide spectrum between soft and hard RT.

(google translate)

Hello.

The hardware is already demanded when many things are displayed.
Is it possible that many equal things can be calculated as a single?

So if a conveyor belt only transported ore, this calculated as one thing and not as 100 or 1 thousandth

The gripping arms can see and take this as a single.
Would that improve performance? (if that's even possible to be programmed)
So this 1000 same graphics than 1 is calculated.

I think you know what I mean.

greeting

How do you efficiently update all entities that are being transported?
Always wondered about that... and did you think about using compute shaders?

Biggest problem with compute shaders is the hardware that properly supports them is already good enough to not need them

ssilk wrote:This is not really true. An application has many possibilities to get CPU time, when it really needs it. There is a wide spectrum between soft and hard RT.

Unfortunately as long as the OS is not a realtime OS like used in the automotive business it will never be "real" realtime. As we can see in the pictures the game will always exceed the 33.333 ms schedule - which is not realtime.
The developers do a great job what can be done on a non-realtime OS!

http://en.m.wikipedia.org/wiki/Real-tim ... _computing

Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

For Factorio: if the render cannot be computed in RT it should not tried and instead the next update should be done.



The result is 30 frames per second instead of 60, but the updates are keeping the 60 fps. The quality of service sinks, but only for the slow computer. The speed for multiplayer is not slowed down.

There can be done much more into that direction, for example reducing the graphic resolution...

For multiplayer the total speed depends on, which processor type is used at minimum. On that depends how the background tasks can be calculated, and how much time slot is used.

And so on.

Thank you for the discussion, I do some programming in my day to day but nothing close to this. I find I learn the most when people not only explain what they are doing but what lead them to such a conclusion.

Nice to see you guys working hard on the core of the game.

Didn't read the artikel on friday. But friday night around 1am my base got into a "glitch" when zoomed out to max level.
did happen before in some rare occasions, but is now constant.

made a bug report of this, https://forums.factorio.com/forum/vie ... f=7&t=8301
but maybe you already fixed it when reading the Friday facts #70. I hope you did

Keep up the good work!