Big tables and performance with love.graphics.draw.

[Bindie]

Hey! Say I have a map of 1 000 000 tiles. How performance heavy is it to iterate through such a list? Of course buffering and displaying only through love.graphics.draw() tiles that are within the window.

I'm making procedural generation, thinking about dividing tiles into specific zones so I only iterate through tile-nrs which I store in the specific zones which also have x,w,y,h so when the player enter it starts to iterate through the zones table only showing the tiles in the zone (for performance of course).

I'm going to try the first approach, if that is too laggy I'll go with the second approach.

Meanwhile, I wonder if someone with a little more experience have a simple way of doing it?

Thanks.

[Nixola]

Unless tiles are quite big and you only draw the visible ones, you're gonna get awful performance. I'd suggest using [wiki]Spritebatch[/wiki]es or [wiki]Canvas[/wiki]es for that. Maybe spritebatches would be better suited for it though.
EDIT: Yay! Broke my fastest response record!

[Bindie]

Well done.

I just got a light bulb.

Of course, I will only draw these tiles within the range of the player and tiles that are on the planet (such as walls) will be replacing the tiles drawn around the player at all times.

[Bindie]

Man I love easy solutions.

[Nixola]

So what solution did you use? Canvases, spritebatches or just limiting the drawn tiles?

[Bindie]

Basically a canvas. Instead of pre-generating tiles that are drawn when the player enters the area I just draw a certain tile image around the players coordinates at all time. So there are no pre-generated tiles, more or less just a background following the player around, but it doesn't look like it.

On top of that I then draw special tiles that are pre-generated such as walls, but since there are far less and for this little game I think it will not be a performance issue.

[Muris]

Even if you have millions of tiles, you only only should draw those that are visible to the screen anyways. There is no point iterating through millions of tiles if only 1000 of them are visible. On the other hand if you do need to update the look on every tile on every frame, then you will most likely have a huge problem.

But ya generally the fastest way to do this would be keeping the list sorted out some way. Like lets say your camera or whatever variable to use for position is at point (900,300), then you should iterate through the list from either point 900 or 300, depending how you arrange the list of objects. Probably the best way would be using tiles with fixed width and height, then you can instantly count the starting point. Then you could use 2-dimensional array and just count the start point. Like lets say width and height of a tile would be 32, then starting point would be (math.floor(900/32), math.floor(300/32)). Then draw as many tiles on the screen as ( math.floor(screen_width/32) + 1, math.floor(screen_height/32) + 1) is.

[Bindie]

Would you like to show me a table arranged in that way? This is how I understand the arrangement:

Code: Select all

t = {
[y1] = {[x1] = {tile1},[x2] = {tile2},[x3] = {tile3},[x4] = {tile4}},
[y2] = {[x1] = {tile5},[x2] = {tile6},[x3] = {tile7},[x4] = {tile8}},
[y3] = {[x1] = {tile9},[x2] = {tile10},[x3] = {tile1},[x4] = {tile11}},
[y4] = {[x1] = {tile12},[x2] = {tile13},[x3] = {tile14},[x4] = {tile15}}
}

Tile1 for example contains imgNrReference and info.

[Muris]

Would you like to show me a table arranged in that way? This is how I understand the arrangement:

Code: Select all

t = {
[y1] = {[x1] = {tile1},[x2] = {tile2},[x3] = {tile3},[x4] = {tile4}},
[y2] = {[x1] = {tile5},[x2] = {tile6},[x3] = {tile7},[x4] = {tile8}},
[y3] = {[x1] = {tile9},[x2] = {tile10},[x3] = {tile1},[x4] = {tile11}},
[y4] = {[x1] = {tile12},[x2] = {tile13},[x3] = {tile14},[x4] = {tile15}}
}

Tile1 for example contains imgNrReference and info.

Pretty much like that, as long as the block (tile) size is same for every single tile. I am not sure if its faster to draw each block into spritebatch on every draw call or draw them all to canvas then copy the area from canvas. The first method probably works a lot better if the blocks can change, and not so sure how well the latter works, if there are limits on how big the canvas can be etc.

If they are different sizes, then it will be a lot harder task + you will have to also have some sort of way to determine z-order as well, in case youl'd draw some blocks on top of some blocks.

[Bindie]

Exactly, z-levels and different tile-sizes are not a priority, guess I will take that some other time.