When using love.math.noise, either the program stops responding or I get some kind of expected results

[rando]

Hello, I'm trying to generate some terrain to make a game similar to Risk. To generate the terrain, I'm using love.math.noise.

Code: Select all

for x = 0, 800 do
	for y = 0, 600 do
		value[x] = value[x] or {}
		xCoord = x / 800 - 0.5
		yCoord = y / 600 - 0.5
		Noise = love.math.noise(xCoord, yCoord)
		value[x][y] = Noise
	end
end

But this code most of the time ends with a blank window that I have to close because it isn't responding. When it doesn't do that, it gets to the drawing code:

Code: Select all

for i = 0, 799 do
	for j = 0, 599 do
		love.graphics.setColor(value[i][j], value[i][j], value[i][j])
		love.graphics.points(i, j)
	end
end

The results are mostly what I'd expect, but there are weird vertical lines that really stick out.

Screenshot (85).png (105.27 KiB) Viewed 7447 times

I have no idea what's going on. Can someone help me please?

[BrotSagtMist]

Running this very code:Whatever problem you have there is not hidden in these lines.

[grump]

Drawing half a million points is probably the worst way to do this.

Code: Select all

local imgd = love.image.newImageData(800, 600)
imgd:mapPixel(function(x, y)
	local n = love.math.noise(x / 800, y / 600)
	return n, n, n, 1
end)

local img = love.graphics.newImage(imgd)

function love.draw()
	love.graphics.draw(img)
end

[pgimeno]

What grump said, but besides, if you place the point in the middle between two pixels, your GL driver is free to pick either side, and it decides that it's fun to pick sometimes the left pixel, sometimes the right pixel. You need to add 0.5 to the pixel coordinates so that they fall in the centre of the pixel. BrotSagtMist's drivers seem not to be so whimsical.

[milon]

What grump said, but besides, if you place the point in the middle between two pixels, your GL driver is free to pick either side, and it decides that it's fun to pick sometimes the left pixel, sometimes the right pixel. You need to add 0.5 to the pixel coordinates so that they fall in the centre of the pixel. BrotSagtMist's drivers seem not to be so whimsical.

Either that, or else draw rectangles that are 1 px in width and height.
But grump's version is better. (And now I'm off to review mapPixel, haha!)

[rando]

I got this fixed on another website. The problem was 100% lag, because of drawing all those points every frame. What I needed to do was render the data onto a buffer and draw that buffer instead of each individual point every frame. One thing I experienced is that canvases didn't work well, and I'm not sure why that was, but imageData works really well.

[grump]

What I needed to do was render the data onto a buffer and draw that buffer instead of each individual point every frame.

Well that's a pretty good solution, ngl.

[zorg]

Canvases are still gpu-side; ImageData isn't. The former was equivalent to what you were already doing, drawing tons of stuff onto a buffer, except the buffer wasn't the game's window, but a canvas; more or less the same thing.

[milon]

... One thing I experienced is that canvases didn't work well, and I'm not sure why that was, but imageData works really well.

Canvases are still gpu-side; ImageData isn't. ...

I know this is kind of off-topic now, sorry about that. But it seems really strange that ImageData (CPU-side) would perform better than canvases (GPU-side). Is that just a strange corner case, or is there a bigger picture that I'm missing?

[grump]

ImageData: lives in RAM, allows easy and fast pixel access. Is just a blob of data and can't be drawn to screen, must be copied into a texture on the GPU first.

Canvas: lives in GPU's VRAM, no easy or fast pixel access, can be rendered to and drawn to screen, does not require copying of pixel data.

You can draw a million polygons to a Canvas to simulate that one mapPixel function, but it's not as efficient. GPUs are just not in the single-pixel business. A fragment shader would be possible, but also much more work.