LÖVE

You're doing something terribly wrong.
What are these 'layers' and why do you need 20 of them?
Why are you rendering them all to canvases and then rendering each canvas instead of rendering them all to one canvas?
I doubt your Spritebatch attemp is good. I'm able to draw 102400 32x16 animated tiles (25 chunks, each consisting of 4096 tiles) on screen, with 150 fps on Intel HD 620 graphics. And my texture page has over 36000 sprites.
I'm not sure what kind of "limitations" you're facing with spritebatches.

EDIT: read the whole thread.
First of all, drawing your whole map to a 4k canvas (bigger than your screen) is silly. You need chunks to draw only the visible area. Top-down math is fairly straight forward.
Second, use VERSION CONTROL like GIT + GitLab/GitHub. That way you'll never lose progress of your code and never worry about breaking something and your Redo button failing.
Third, post a .love if you want people to help you better. We won't "steal" your game, we're too busy trying to make our own games.

As I said, your task is fairly lightweight and shouldn't run into FPS issues, unless you have a 4k screen or something. You're clearly doing something wrong, love2d is more than capable.

KayleMaster wrote: ↑Mon Feb 24, 2020 7:30 pm Third, post a .love if you want people to help you better. We won't "steal" your game, we're too busy trying to make our own games.

He posted (the relevant fraction of) his code. Presumably it's bottlenecked by the CPU due to having to work through pretty ridiculous amount of data before a tile can be rendered.

Yeah but he's drawing to the "canvases" only at start, so what CPU bottleneck? It's obviously CPU since he has integrated video graphics, but you get my point. I think it's the 20 4k x 4k canvases he's trying to draw.
But I just want to see why he chose this over complicated method instead of everything else... He could have packed the art in a single texture page and just have some for loops for the draw calls in the same order he wants to draw the layers and he'll be way better off.

I think this topic has gotten a bit far off the mark of what I was trying to get help with. Let's start this over with the question I should have asked. How does one efficiently proceed with rendering a tilemap when said tilemap consists of a large number of layers which all require rendering over one another with various RGBA effects? All I'm looking for is an understanding of what approach I should be taking here. I don't want anyone to write code for me, I just want a clear explanation of what the best way to proceed would be.

EDIT: Incidentally, I tested my methodology in a much more basic environment (single pre-loaded image, no math being performed for positioning or pulling the tile up, fixed 800x600 canvases instead of 4096x4096 ones) and got very similar results. So apparently the heavy amount of math I'm doing to find the tiles is a drop in the pan and the core problem is in my rendering methodology.

You just shove your entire map into a spritebatch, in the order in which each tile would be rendered, accounting for layers and all. Particularly gigantic maps may need splitting into chunks but yours are very small. You can break up the batch if your effects necessitate a shader switch (or uniform update which is equivalent in practical terms) or using a different blending mode. Worst case scenario that would be done once per layer so you'd have in vicinity of 30 batches, which is again a very modest amount and should run flawlessly on a smart refrigerator.

Let's back up a bit actually. Do other tile-based LOVE games run well on your machine?

raidho36 wrote: ↑Mon Feb 24, 2020 11:24 pm You just shove your entire map into a spritebatch, in the order in which each tile would be rendered, accounting for layers and all. Particularly gigantic maps may need splitting into chunks but yours are very small. You can break up the batch if your effects necessitate a shader switch (or uniform update which is equivalent in practical terms) or using a different blending mode. Worst case scenario that would be done once per layer so you'd have in vicinity of 30 batches, which is again a very modest amount and should run flawlessly on a smart refrigerator.

Let's back up a bit actually. Do other tile-based LOVE games run well on your machine?

Yeah, that kind of sounds like how I was trying to render. In fact, the method I came up with via Canvases actually ends up being more efficient than that on this laptop, which I'm pretty sure should never happen!

I've never actually tried running any LOVE games on this but my own. It is entirely possible that this particular model of Acer has issues with this! If you can point me in the direction of a tile-based LOVE game that's using lots of layers and is known to run fine on normal systems, we may well get some resolution on this one.

Okay, now it's really getting weird! I tried checking the CPU usage on the testing environment I built, and it was using sub-4% of the CPU when it started dropping below 60FPS. The main game, meanwhile, consumes around 8 to 12% of CPU power when just at the 60FPS threshold. It's like something is throttling LOVE's rendering subroutines somehow. What could do that?

EDIT: Further testing reveals that the GPU is getting pushed absurdly hard by each draw command it parses. We're talking 12% of the GPU's power getting eaten up by only 480 draw commands of 32x32 images. Something is REALLY wrong here!

480 draw calls eating 12% of the GPU power sounds about right, in by book that's pretty generous actually. Batching will reduce the amount of draw calls. If you were using version 11 or later there should be autobatching enabled; check the output of love.graphics.getStats.

raidho36 wrote: ↑Tue Feb 25, 2020 12:33 am 480 draw calls eating 12% of the GPU power sounds about right, in by book that's pretty generous actually. Batching will reduce the amount of draw calls. If you were using version 11 or later there should be autobatching enabled; check the output of love.graphics.getStats.

That's the thing, though: that's 480 batched draw calls doing that! Effective draw calls is only 2. Here's what it's outputting when I'm at the limit: 2 drawcalls, 0 canvas switches, 63366400 texture memory, 4 images, 2 canvases, 1 font, 21 drawcalls batched.

EDIT: By comparison, a direct-draw method (ie. draw sprites one by one in the love.draw function) renders 5761 drawcalls batched before it starts to falter. I think somehow the efficiencies you're supposed to get from SpriteBatches and Canvases are being lost.

EDIT 2: Well I can confirm it doesn't happen on newer hardware, at least! I just tested on my main PC and the FPS stayed a solid 60 even when doing 28,800 draw calls per cycle.