LÖVE

I want to create very advanced citybuilding game. The problem is rendering the world, which is divided for chunks (128x128). Each chunk is a square 128x128 tiles. I want to generate these chunks tile by tile. So how much images can love2d display at one time? I need to know that to optimize the way, I am going to create world. And sorry for my English

Well, depends on CPU and GPU.
The best way, if the tiles are small, is to use canvases. Render it once, then draw the entire canvas. This way there is no real limit.
If your tiles are animated or too big, use a spritebatch and a texture atlas.
Or use both, for example when zooming in, use the spritebatch with animated/high res textures, else the pre rendered canvases.
Note that the most costly part is the draw call itself (love.graphics.draw for example), a spritebatch however can draw several thousands on even notebook gpus without problems (since the most work is done on the faster gpu)

To add to Luke's post, it is worth noting that in the last few releases of LÖVE draw calls get automatically batched (since 11.0). So if you are drawing multiple quads from the same source image one after another, without modifying the love.graphics state (eq. setting a canvas, shader, color, etc), it will all be done in a single draw call (according to love.graphics.getStats, anyway). That doesn't mean you shouldn't try to optimize how you draw stuff onto the screen, but these days it technically requires less conscious effort.

At the end of the day you still need to write your code, see if there are any performance issues, and then address the bottlenecks if they are significant enough.

Technically infinite, but rendering the frame could take a while.

Your biggest constraint is number of GPU draw calls; modern OpenGL drivers can eat through 150k-200k per second without completely choking. Using Vulkan this value is bumped up by a large multiple, but still limited, and this driver is not currently available in LOVE. Draw call is generated when you switch current texture, when you switch current render target, when you switch current blending mode, when you switch current shader, when you change shader variables (counted individually), and so on - and of course when you actually render something. So your main job is to draw more stuff using less GPU calls. The first thing you do is use a texture atlas, so that between drawing different sprites there's no texture change call. The second is using sprite batch for rendering, where multiple sprites are rendered using a single draw call. Finally, you organize render order such as to render consecutively as many sprites as possible without switching drawing modes, shaders, etc. If you have to use multiple atlases, switching an atlas also counts for this and must be factored in.

One thing you'll want to know about city builders, at least older ones, is that it usually updated the whole city in chunks offset by a few frames so it's not trying to calculate everything all at once in one frame. So since you're already rendering by chunk, do the updating and calculating by chunk too. Start at the top corner and go one chunk at a time like an old CRT's electron beam would work until it gets to the bottom opposite corner then start over. At times you'll have to check stuff that's outside of a chunk's bounds but that's fine as long as you're not trying to calculate everything all at once.

Also don't try and draw it all at once except in a zoom mode where it will then render everything to a large canvas and display that. Think small. Don't try to go too big right away. Work up to it.