Friday Facts #324 - Sound design, Animated trees, Optimizations

[coppercoil]

That math is far off, unfortunately. Unpacking bit-packed structures like that is not free. Especially not if placed on arbitrary offsets, that's 6-10 extra instructions just for unpacking, including offset-calculation, bit-arithmetic etc., with the nasty side effect of massive register pressure negatively impacting assembly of the surrounding logic. Add to that overhead from loosing the ability to use any form of vector instruction, due to unsuitable alignment. Minimal sensible alignment for the structure is 16 byte, anything other than a multiple of that comes with several severe catches. Also 18 bits for X and Y combined? How far do you think you can get with a range of 0-512 in either direction? Update logic does not stop at the edge of a chunk.

Furthermore, there still isn't a sensible memory layout in most cases. Serializing by depth first traversal order of spanning tree is already as good as it gets, and even that only performs well in very few scenarios like main-bus etc. And whenever some entity updates, you have to rebuild the tree, reorder the components, inform the owning entities that their components memory locations just shifted, and generally accept the limitation that you can now never again hand out a pointer / index into the component storage without living in constant fear about index invalidation issues. Meaning, now you can't even establish a proper linked data structure within a component type, without bouncing back via the owning entity!

I gave 18 + 18 bits for X and Y. I agree, that can be not enough, that's just an example. 16 bytes may be still good achievement.
State bits unpacking shouldn’t be a problem, register bit masking and shifting are superfast operations.

Tree traversing issues does not impress me. Trees should be avoided where possible, period. Binary search likely is evil too. Those are really impressive restrictions for a developer

[bleistift2]

• Each tick; check if the inserter has a burner energy source. If it does:
  • Check if the energy source is completely empty and go to sleep if so (no fuel, can't move fuel into itself since it can never move).
  • Check if the item in the inserter hand can be used as fuel for this inserter. If it can:
  • Move the hand towards the inserter itself.

I never knew burner inserters could feed themselves That adds some real usefulness to them!

Every save file I've tested ended up running measurably faster in the end. The most extreme one (lots of steel furnace based smelting) showed a 2.3x speed-up.

And here I am, playing Anno 2070 (I know, heathen!), and getting angry at the devs for taking half a second to pan the view to a ship I was selecting via hotkey. In all games I’ve played since Factorio, I always end up thinking, “Wube wouldn’t have settled for this crap.”

Stop spoiling me for future games, Wube!

[jaggmann]

Is there an audio event for each animation .Perhaps that is too much .What about sound templates or themes for area zones .This is already the case .If the player is near electric furnaces then that is the sound context .Perhaps biters need an interesting alarm that changes ,modulates ,differently .An evolving sound as they approach ? I have made some sounds .What do people think of theses when it comes to biters ? Found on SoundCloud , QUAVERTUNE .mab # modular 0199 ,Alarm mab # modular 0188 .

[Trebor]

I never knew burner inserters could feed themselves That adds some real usefulness to them!

This why many backup steam power units incorporate them, they will startup on their one once fuel is restored.

[Ormy]

Holy crap, what a FFF! It's like you guys read my mind and got to all of the things I could have hoped for all in one week!

If I could just ask one more tiny thing. With the sound redesign, could the "listener" be changed to the engineer instead of the camera? I spend so much of my time fully zoomed out, and I fear I'll miss out on all of this great sound work. It feels very odd while playing that sounds don't play in relation to my avatar.

Thank you!

Please Devs if you are going to implement this suggestion make it a toggle-able option, I do not want to always hear the sounds from the engineers perspective. My factory has large amounts of inserters and bots everywhere, when I zoom in its nice to hear everything working but I couldn't put up with that kind of noise for very long. I like to be able to zoom out and escape the droning noise of the factory.

This is all great. Good work everyone.

With this new even framework, can you please implement the ability to set not yet researched recipes on factories especially from blueprints. It often happens that we have many blueprints built up in our library for many different things over the many many games we have played. When playing again, your research order will not be the same as last time and when you put down a blueprint, anything that is not yet researched will not be set on the factories in the blueprint. This is not intuitive and behaves differently then everything else set from blueprints (viewtopic.php?f=6&t=28954).

Also it's good to have tree animations and it looks better then not having them, but somehow they still look a bit like just using a noise function and not the actual leaves moving. It looks like a distortion filter was just applied to slightly pull and push parts of the tree sprite.

Thanks

I strongly second this suggestion. There is a big inconsistency here, consider the two situations below.

A: I place a blueprint that contains buildings that I haven't researched yet. If I have those buildings in inventory anyway (i.e. cheated them in using console) the game doesn't care that I cheated and places the buildings anyway. If I don't cheat and just wait till I research and manufacture those buildings, as soon as they are available on the logistic network they bots will place them. So I can place a blueprint for non-researched buildings and it'll just work without further intervention when those buildings are researched and made available.

B: I place a blueprint that contains buildings I have researched and have available, but that building's blueprinted recipe is not researched yet. Once the recipe is researched, I have to go back to that building and select the recipe, a further intervention that is not required it situation A.

Obviously we can't have buildings processing recipes that are not researched yet, that's cheating. Maybe some kind of placeholder recipe could be created, so the building doesn't actually produce the recipe (even if ingredients are available) but as soon as the recipe is researched the building and its recipe are activated without manual intervention from the player.

Or maybe the bots should simple not place a building if its recipe is not researched, and then place the building with the recipe when the recipe is researched? Or would that create too many checks and harm UPS?

[bleistift2]

[…] If I could just ask one more tiny thing. With the sound redesign, could the "listener" be changed to the engineer instead of the camera? […]

Please Devs if you are going to implement this suggestion make it a toggle-able option, I do not want to always hear the sounds from the engineers perspective. […]

If I may add to this, just in case it does get the developers’ attention: I always found it strange that the sounds around the (actual) character position got louder when one was zooming in on some other place in the map.

[LostInTheForums]

Do you know about the game Knights and Merchants? It had such a beautiful graphics with animated trees even though it was back in '96 I recall? Factorio trees should be like that I believe.

[Ranger_Aurelien]

I never knew burner inserters could feed themselves That adds some real usefulness to them!

This why many backup steam power units incorporate them, they will startup on their one once fuel is restored.

My backup power system has a separate coal power system to power the main coal burner inserters, and the burner inserters of the backup system are they themselves fed by red reach inserters from a separate belt of coal (with inserter count boosts that keeps the burner inserters above minimum...)

[bobucles]

I gave 18 + 18 bits for X and Y. I agree, that can be not enough, that's just an example. 16 bytes may be still good achievement.
State bits unpacking shouldn’t be a problem, register bit masking and shifting are superfast operations.

There's always a way to trade off between CPU cycles and memory storage. There's even some proof of concept FPS games that fit all their content into a 200kB executable. I'd try uploading it but the entire game is buried somewhere in my archives.

Pinching pennies does not always mean improved performance. While unpacking a multi purpose variable may be fast, it still takes time. During that time the other pieces of that variable require special treatment, and then it has to be repacked when it's done. That's a lot of extra baggage to save what? A byte here, a byte there? Save that kind of effort for micro architectures like AVR, where every single byte is a precious resource.

It won't even be equally effective across all PCs, since you're starting with an assumption that every computer has a fixed amount of CPU power per RAM power. A 16 core monster can happily trade a mountain of CPU cycles for a pinch of RAM all day, but a dual core system will get annihilated by the same exchange rate. It's a nasty game to play and ultimately there are superior places to save performance.

[coppercoil]

While unpacking a multi purpose variable may be fast, it still takes time.

Cache misses takes much more time. Even hyperthreading was born

Dualcore system shouldn't be considered as primary dev's target. Does anybody care about Android 4.4? They still exists...

[Koub]

I gave 18 + 18 bits for X and Y. I agree, that can be not enough, that's just an example. 16 bytes may be still good achievement.
State bits unpacking shouldn’t be a problem, register bit masking and shifting are superfast operations.

There's always a way to trade off between CPU cycles and memory storage. There's even some proof of concept FPS games that fit all their content into a 200kB executable. I'd try uploading it but the entire game is buried somewhere in my archives.

Pinching pennies does not always mean improved performance. While unpacking a multi purpose variable may be fast, it still takes time. During that time the other pieces of that variable require special treatment, and then it has to be repacked when it's done. That's a lot of extra baggage to save what? A byte here, a byte there? Save that kind of effort for micro architectures like AVR, where every single byte is a precious resource.

It won't even be equally effective across all PCs, since you're starting with an assumption that every computer has a fixed amount of CPU power per RAM power. A 16 core monster can happily trade a mountain of CPU cycles for a pinch of RAM all day, but a dual core system will get annihilated by the same exchange rate. It's a nasty game to play and ultimately there are superior places to save performance.

Might not be what you're looking for but :
http://www.farbrausch.de/
especially fr-08 .the.product (an exe file less than 64kB containing ... a 11-ish minutes 3D animated short movie with music and all (wait for the end of the scroller).
Well ... The link is dead on the website so you can use the verion I dled back then.
They also did a FPS game demo in 96kB .kkrieger (also included)

[mrvn]

This is another nice example of "Factorio is not CPU bound, it's memory latency bound". More cores wasn't going to make this faster - because it was never limited by how fast the CPU ran.

uhh what? no.
more cores weren't going to make this faster, because no N-threaded program will run faster if you just "throw more cores at it" (i.e. if you already have N cores and add more).
number of cores != speed of the CPU.

and another thing:

1 of the 3 always takes significantly longer to finish than the others. That means that the others end up being essentially "free"; the game has to wait for the slowest to be finished anyway so the faster 2 of the 3 get a "free ride" to finish long before game finishes waiting for the slowest to be done.

i don't know what you mean by "free ride", they're still being computed, it's all weirdly worded.

if one of them takes significantly longer than the other 2, how about make it run parallel to the other 2 being run sequentially?
as in:

Code: Select all

------1------->
--2--> --3-->

this way they won't compete as hard for resources - however, of course, overall they will compete for a bit longer

No, go the other way. Figure out which subsets of 1, 2 and 3 don't interact with each other and then do

Code: Select all

------1a------->------1i------->
------1b------->------1j------->
------1c------->------1k------->
------1d------->------1l------->
------1e------->------1m------->
------1f------->------1n------->
------1g------->--2a-->--2b-->
------1h------->--3a-->--3b-->

[dee-]

I gave 18 + 18 bits for X and Y. I agree, that can be not enough, that's just an example. 16 bytes may be still good achievement.
State bits unpacking shouldn’t be a problem, register bit masking and shifting are superfast operations.

There's always a way to trade off between CPU cycles and memory storage. There's even some proof of concept FPS games that fit all their content into a 200kB executable. I'd try uploading it but the entire game is buried somewhere in my archives.

For example .kkrieger by german demogroup farbrausch, it's 97,280 bytes.

About:
https://en.wikipedia.org/wiki/.kkrieger

A clueless review but good video capture:
https://www.youtube.com/watch?v=_qrsHqDF4BA

Get it here:
https://www.pouet.net/prod.php?which=12036


Edit: I've just seen the post by koub

[Tekky]

Thank you very much for spending the effort on optimizing the performance even further. Factorio truly is a masterpiece, both from a design and a technical standpoint.

[BlueTemplar]

While unpacking a multi purpose variable may be fast, it still takes time.

Cache misses takes much more time. Even hyperthreading was born

Dualcore system shouldn't be considered as primary dev's target. Does anybody care about Android 4.4? They still exists...

They should be considered as the minimum requirements targets, however... (Even i3's are dual core !)

[Shingen]

1 of the 3 always takes significantly longer to finish than the others. That means that the others end up being essentially "free"; the game has to wait for the slowest to be finished anyway so the faster 2 of the 3 get a "free ride" to finish long before game finishes waiting for the slowest to be done.

i don't know what you mean by "free ride", they're still being computed, it's all weirdly worded.

if one of them takes significantly longer than the other 2, how about make it run parallel to the other 2 being run sequentially?
as in:

Code: Select all

------1------->
--2--> --3-->

this way they won't compete as hard for resources - however, of course, overall they will compete for a bit longer

No, go the other way. Figure out which subsets of 1, 2 and 3 don't interact with each other and then do

Code: Select all

------1a------->------1i------->
------1b------->------1j------->
------1c------->------1k------->
------1d------->------1l------->
------1e------->------1m------->
------1f------->------1n------->
------1g------->--2a-->--2b-->
------1h------->--3a-->--3b-->

well, obviously i made that suggestion as a very simple to achieve improvement (assuming 1 is at least as long as 2+3), and kinda on an assumption that for whatever reason they can't (or it's not worth it to) just break them into smaller pieces running parallel to each other.
your solution is much more complicated and the overhead may just not be worth it, but if it was, then sure, why not?.

[prodacc]

Any sign of the patches coming back into stock?

[Jap2.0]

Any sign of the patches coming back into stock?

They're ramping up for another major/breaking (i.e. in the mod api sense) release, 0.18. (So probably no more 0.17.x releases.) 0.18's also not until after Christmas.

[runamucker]

The tree effect looks like the leaves are flowing in two opposite directions at once, roughly along the NE-SW axis, and it's uncomfortable to look at. Also, this movement applies so evenly across the texture that it makes them look flat like water.