Friday Facts #112 - Better noise

[kovarex]

Guys, do you know that the whole noise thing is supposed to be only performance improvement? At this stage, at least.

Meh, just thread world generator more and we'll have faster stuff.
Like why all passes have to run in 1 core? Can't they just make 1 core prepare 1 part then 2nd core process it while 1st core is preparing new and with all 4 world generation passes it could be sequenced a bit faster? If you also throw in that new faster algorithm, it should be insanely fast?

Isn't it better to make it 10 times faster on one core, than having to use more cores for it?

[aka13]

Easier, but not necessary better.

Since the new intel leak for the k-Series with 10 cores and 20 threads, I think multicore has a brighter future.

[TuckJohn]

I really like the longer post- I would love to see more FFF like it.

[kovarex]

Easier, but not necessary better.

Since the new intel leak for the k-Series with 10 cores and 20 threads, I think multicore has a brighter future.

No, it is really better to make the algorithm faster on one core, when it is possible, other cores can always be used for other things, the power consumption is lower and it always can be multithreaded but only as a last resort, and would be more effective anyway.

[aka13]

From my humble experience, projects which were not built ground-up with multithreaded support from the beginning tend to never end up having proper multithreading, simply because of the expenses and complexity of the said task after most of the project is complete. But I have no large field experience with that, so not arguing with you.

[Tev]

Guys, do you know that the whole noise thing is supposed to be only performance improvement? At this stage, at least.

Considering popularity of RSO people would like if you try to improve more than "only performance" . . .

[kovarex]

From my humble experience, projects which were not built ground-up with multithreaded support from the beginning tend to never end up having proper multithreading, simply because of the expenses and complexity of the said task after most of the project is complete. But I have no large field experience with that, so not arguing with you.

Well, the map generation was done in the same thread before and now it runs parallel with game, so we have done step like this already. Going from "running in one separate thread" to "running in x separate threads" would be much easier.

The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.

[Phillip_Lynx]

... Considering this argument, optimising it on single core is even better.

Thx for this. I am on a 2 core / 4 threads computer and have not the money to get a better rig. The house is eating up all my money .

[Lee_newsum]

The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.

Yes for Multiplayer game but you have to tink some of the one player game. can you add this like this that work of one player games?

p.s. i have i7 6 core / 12 threads computer i have the threads to use.

[Kayser]

I'm not a huge fan of the results of the current map generator. I understand that the devs want to be able to calculate any point of the map independently of all others, but that constraint it is getting in the way of creating fun, variable, interesting maps with replayability value. I'm sure a better map generator could be found if that constraint was dropped. Don't get me wrong, it could still be infinite.

Not sure what you mean by "...be able to calculate any point of the map independently of all others...", but can you explain what constraints such approach inherently has?

It means that when determining the properties for a point on the map the algorithm can't look at e.g. adjacent points to determine what properties the new point has; instead it must base its calculations only on the seed and parameters given initially. This rules out generating maps based on procedural algorithms that simulate e.g. rainfall or erosion.

[Kewlhotrod]

Easier, but not necessary better.

Since the new intel leak for the k-Series with 10 cores and 20 threads, I think multicore has a brighter future.

thats the intel extreme part for enthusists, like 600£ cpu if not more, although no details on the price of the parts have been released yet although judging by the price of there last enthuist part it would be costing more because of more cores.

[kovarex]

The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.

Yes for Multiplayer game but you have to tink some of the one player game. can you add this like this that work of one player games?

p.s. i have i7 6 core / 12 threads computer i have the threads to use.

When the performance becomes an issue, it will be probably related to game updates. And it is a good point for multithreading, as you have to calculate it anyway. Some things are especially good for multithreading, like electric network calculations.

[ratchetfreak]

Well, the map generation was done in the same thread before and now it runs parallel with game, so we have done step like this already. Going from "running in one separate thread" to "running in x separate threads" would be much easier.

The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.

What actually needs to happen is that a request to gen a map tile and the actual insertion into the game logic should be allowed to have a few game ticks between them. Then you can offload the generation to another threadpool and come back later for the result to push it into the game world.

In multiplayer you can use a ballot of who's finished with the generation to decide whether to insert the tile yet (or to perform a download of the tile data by the slower PCs).

[kovarex]

Well, the map generation was done in the same thread before and now it runs parallel with game, so we have done step like this already. Going from "running in one separate thread" to "running in x separate threads" would be much easier.

The problem with using lot of cores is, that we can't do it. The game needs to generate the map slow enough, to make it still smooth on the worst computer we want to support. We can't generate faster on faster computers, as the game needs to be deterministic.

Considering this argument, optimising it on single core is even better.

What actually needs to happen is that a request to gen a map tile and the actual insertion into the game logic should be allowed to have a few game ticks between them. Then you can offload the generation to another threadpool and come back later for the result to push it into the game world.

This is exactly how it works in Factorio.

In multiplayer you can use a ballot of who's finished with the generation to decide whether to insert the tile yet (or to perform a download of the tile data by the slower PCs).

I strongly believe, that the extra bandwith and replay size wouldn't be worth it. Isn't just making the map generation 10 times faster simpler?
Actually, if the map generation becomes very fast, it can be even worth of not saving most of the terrain in map save and re-generate it when loading the map. (The other way around)

[ratchetfreak]

In multiplayer you can use a ballot of who's finished with the generation to decide whether to insert the tile yet (or to perform a download of the tile data by the slower PCs).

I strongly believe, that the extra bandwith and replay size wouldn't be worth it. Isn't just making the map generation 10 times faster simpler?
Actually, if the map generation becomes very fast, it can be even worth of not saving most of the terrain in map save and re-generate it when loading the map. (The other way around)

Then the map download when joining a multiplayer game will also be reduced

[tobsimon]

Did I just read "better rail system".
I sure hope this includes a fix for the "circles" *cough* *cough*.

[cube]

It means that when determining the properties for a point on the map the algorithm can't look at e.g. adjacent points to determine what properties the new point has; instead it must base its calculations only on the seed and parameters given initially. This rules out generating maps based on procedural algorithms that simulate e.g. rainfall or erosion.

Not entirely, I hope. I was thinking about this for some time, and I think that we can cheat this a little. Already there is a mechanism where every chunk has a level to which it is generated (now it is raw tiles, corrected tiles, tile variations, entities) and there is a rule that chunk with level n must have all neighbors at least on level n-1. So we could add a level after raw tiles that looks at the neighbors' raw tiles and does some erosion fun. Theoretically.

[Furan]

While you're at it, please consider reworking the structure of the resources. At this point they are generally homogeneous convex patches.
I'd like to see stripes resembling stratification. Use a periodic function (triangle wave) on the main terrain noise, ultimately creating distinct or blurred bands parallel to the coastline.

[Kayser]

It means that when determining the properties for a point on the map the algorithm can't look at e.g. adjacent points to determine what properties the new point has; instead it must base its calculations only on the seed and parameters given initially. This rules out generating maps based on procedural algorithms that simulate e.g. rainfall or erosion.

Not entirely, I hope. I was thinking about this for some time, and I think that we can cheat this a little. Already there is a mechanism where every chunk has a level to which it is generated (now it is raw tiles, corrected tiles, tile variations, entities) and there is a rule that chunk with level n must have all neighbors at least on level n-1. So we could add a level after raw tiles that looks at the neighbors' raw tiles and does some erosion fun. Theoretically.

Alright. I'm looking forward to it

[Gandalf]

So cube, I see you're using Awesome as well?

Love the tech-talk. It made me realize how little I know about non-cryptographic hash functions.