Procedural terrain generation is very slow

Question

I've been trying to create procedural generated 2d terrain (similar to a game like Terraria) using Simplex noise. I was able to get the noise function working, and I set up a grid of 16 by 16 tiles that uses the noise to generate the height of the terrain. The problem is that the grid generation is rather slow. I often need to wait 5 - 10 seconds for a somewhat small grid to generate.

My code looks like this:

var level; // height of the terrain
generate_simplex_octaves2D(__largestfeature, __persistance, seed); // generate octaves using __largestfeature

for (var gy = 0 ; gy < global.__gridheight ; gy++)
{
    for (var gx = 0 ; gx < global.__gridwidth ; gx++)
    {
        level = (global.__gridheight div 2) + (100*get_noise2D(gx/100, gy/100, __octaves, __frequencys, __amplitudes)); // get noise value at point (gx/100, gy/100)
        if (gy > level) // if below level
        {
            global.__testgrid[# gx,gy] = TILE_FULL; // set grid position to a full tile
        } else global.__testgrid[# gx,gy] = VOID; // set grid position to an empty tile

        if (global.__testgrid[# gx,gy] == TILE_FULL) tilemap_set(global.testmap, 1, gx, gy);
    }
}

This creates terrain that looks fine, it's just too slow. I want to be able to generate terrain in real-time to create an infinite landscape. After doing some research, I found that I could maybe use a compute shader to have the GPU help speed up the generation, but I am not sure how to implement a compute shader in my case. Would I calculate the noise in a shader, or generate a noise map using one? Or do something else to generate the terrain faster?

Answer 1

I can see 2 possible reasons of bad performance:

1. You have very big numbers in X and Y. Like 2000*1000. In this way you must lower that. You can make bigger areas to generate (like 10*10 squares instead of 1*1). Or you can regenerate many possibilities for squares of 50*50 and randomly select them.

2. Or it can be very hard function: get_noise2D(gx/100, gy/100, __octaves, __frequencys, __amplitudes). You can use lighter version of this or just random generator.

Answer 2

I'm seeing get_noise2D() and tilemap_set() as potential problems here. You didn't write them (?), so you don't know what's happening inside them. The high likelihood is there are heap memory allocations (new operator) going in inside there and it's causing your system to really chug as the CPU pipeline stalls while it waits for those allocations to return from main memory.

What you really need to do here is write dummy versions of each of these functions (or replace them basically) without any logic inside, and see which of these causes the gen-time to shoot up. So try dummying one, then the other, and see which impacts duration. Hopefully, gutting the first function doesn't cause the remaining logic to crash, else you'll have to supply dummy outputs therefrom.

Your nested loop and conditionals therein are, in my experience, not enough to cause serious slowdowns, even though nesting loops and conditionals is generally something you want to keep to a bare minimum.