It could, but I consider it to not be worth the trouble.immibis wrote:Could the "middle lane" be re-added with the new belt system? It seems a lot more natural than having all the items move to one side for no reason.
Friday Facts #82 - Optimisations
Re: Friday Facts #82 Optimisations
-
- Burner Inserter
- Posts: 16
- Joined: Wed Apr 30, 2014 7:49 pm
- Contact:
Re: Friday Facts #82 Optimisations
Awesome update! Always love you technical insights.
I would suggest to group accumulators as well as solar panels. The code is probably quite similar.
I would suggest to group accumulators as well as solar panels. The code is probably quite similar.
Re: Friday Facts #82 Optimisations
Will this restrict modding abilities? There's mods such as Belt Blocker that rely on physical simulation of items.kovarex wrote:For 0.12, I completely rewrote the internal logic of all the transport belt related entities (belt, underground belt, splitter). The items on the belts are no longer represented as individual entities. These are just very simple internal structures moving on small invisible "rails".
Re: Friday Facts #82 Optimisations
is it possible to use the same optimastions on accumilators that are developed for the solars? it seams to me that they shuold be quite similar in the simulations.
Re: Friday Facts #82 Optimisations
Does the new belt system mean corners are finally going to work properly?
Re: Friday Facts #82 Optimisations
Yes corners don't slow limit the throughput now.Zeblote wrote:Does the new belt system mean corners are finally going to work properly?
Yes, accumulators could be also grouped.MeinAccount wrote:Awesome update! Always love you technical insights.
I would suggest to group accumulators as well as solar panels. The code is probably quite similar.
Re: Friday Facts #82 Optimisations
:Dkovarex wrote:Yes corners don't slow limit the throughput now.Zeblote wrote:Does the new belt system mean corners are finally going to work properly?
Re: Friday Facts #82 Optimisations
Some people will not like that news, but I do - I really like this "bug" fixed.
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: Friday Facts #82 Optimisations
Almost 10% of the update time is spent on "Smoke", a graphical effect that has no practical purpose, other than to look good.
Yeah, that does sound like a bit of a waste of processing power when compared to the fact that the other 90% has a practical purpose.
Yeah, that does sound like a bit of a waste of processing power when compared to the fact that the other 90% has a practical purpose.
Re: Friday Facts #82 Optimisations
Yeah, that's why I play with the smoke turned offbobingabout wrote:Almost 10% of the update time is spent on "Smoke", a graphical effect that has no practical purpose, other than to look good.
Yeah, that does sound like a bit of a waste of processing power when compared to the fact that the other 90% has a practical purpose.
Re: Friday Facts #82 Optimisations
Why quotes? It is a bug, a real convyor belt corner would not work like that. Items on the outer row would be spaced out but moving faster, both sides still getting the same ammount of pieces around the corner.Nova wrote:Some people will not like that news, but I do - I really like this "bug" fixed.
Re: Friday Facts #82 Optimisations
That has no effect on it. That just stops the smoke from rendering. It still exists and it still ticks down its life time and "floats" around.JimiQ wrote:Yeah, that's why I play with the smoke turned offbobingabout wrote:Almost 10% of the update time is spent on "Smoke", a graphical effect that has no practical purpose, other than to look good.
Yeah, that does sound like a bit of a waste of processing power when compared to the fact that the other 90% has a practical purpose.
If you want to get ahold of me I'm almost always on Discord.
Re: Friday Facts #82 Optimisations
Realism has nothing to do with something being a bug or not. The only question is: Was / is it intended or not? If no, than it's a bug, but I'm not sure if this was ever intended or not. ^^Zeblote wrote:Why quotes? It is a bug, a real convyor belt corner would not work like that. Items on the outer row would be spaced out but moving faster, both sides still getting the same ammount of pieces around the corner.Nova wrote:Some people will not like that news, but I do - I really like this "bug" fixed.
-
- Inserter
- Posts: 21
- Joined: Sun Mar 01, 2015 1:08 pm
- Contact:
Re: Friday Facts #82 Optimisations
Heya, great news on the performance improvements.
As an idea regarding smoke:
If smoke is really such an issue performance wise, how about adding a 2nd tier train that doesnt produce smoke (i.e. electricity based,using accumulators and some kind of charging device at stations). This would do the same as the solar cells, during beginning and mid game (where performance is usually no issue) a lot of smoke can be produced and calculated without issues, whereas in lategame, where performance really matters, most people would have replaced steam engines with solar cells and diesel trains with electric trains, meaning there is not much smoke to calculate.
As an idea regarding smoke:
If smoke is really such an issue performance wise, how about adding a 2nd tier train that doesnt produce smoke (i.e. electricity based,using accumulators and some kind of charging device at stations). This would do the same as the solar cells, during beginning and mid game (where performance is usually no issue) a lot of smoke can be produced and calculated without issues, whereas in lategame, where performance really matters, most people would have replaced steam engines with solar cells and diesel trains with electric trains, meaning there is not much smoke to calculate.
Re: Friday Facts #82 Optimisations
How about better multi-threading? It seems for me even better than 20% optimization, as game could use all my 8 CPU cores and don't lag.
Re: Friday Facts #82 Optimisations
We are keeping this for laterTeDeum wrote:How about better multi-threading? It seems for me even better than 20% optimization, as game could use all my 8 CPU cores and don't lag.
Also it is quite logical to first optimise the core performance first.
Re: Friday Facts #82 Optimisations
Great Friday Facts!! Would love to see the higher resolution entities for 0.12 like mentioned in FF64
Re: Friday Facts #82 Optimisations
I wonder if main thread threading is planned, because you could build 4x ish bigger factories on quadcore cpu.
Re: Friday Facts #82 Optimisations
The original idea here was to simulate different chunks in different threads. However this is quite tricky to do properly - namely because overlaps and special cases. Another approach we have been thinking about recently is to do some "thematic" parallelization. Things like electric energy propagation, path finder, rail finding.cpy wrote:I wonder if main thread threading is planned, because you could build 4x ish bigger factories on quadcore cpu.
Also the game uses a few threads already. During the update there is the update thread, render thread, map generation thread, multiplayer socket processing thread and some more in the allegro library. So the speedup will be less than linear.
Anyway, for now we prefer to do single thread optimizations because there is better ratio of gain / work and they are less error prone.
Re: Friday Facts #82 Optimisations
Yes. The goal is to make it playable even with 1s latency. However the latency hiding won't be perfect. This involves some dirty internal tricks, therefore we decided to go for most common actions. Things like moving, building, mining, etc. They will be (unless there is a collision) instantaneous. However in non-latency hidden actions the lag will still be felt. More on this will be in the fff.vegeta897 wrote:Does this mean things like movement will be rendered client-side instantly before actually being simulated? Thus making playing with 200ms ping not feel so delayed?Tomas is working on the lag hiding and it seems to have nice results, you can expect detailed description of it in the next fff.