Large worlds render slowly

[pmer]

Areas larger than the screen spend CPU time trying to draw tiles that are not even onscreen.

https://github.com/seisatsu/Driftwood/blob/35d8dce45e514e4726b0a9fc8a8c3d8808b90499/src/areamanager.py#L156

Driftwood should only try to draw tiles that will appear onscreen. It can calculate a rectangle of tiles that will appear on the viewport and only loop over those.

https://github.com/pmer/TsunagariC/blob/1f5eeb41a7267478782885f77899753937a6a4f9/src/core/area.cpp#L141

[seisatsu]

Isn't this a duplicate of #157?

[pmer]

Oh, perhaps I am misunderstanding #157? I thought #157 was for the time it takes an area to initialize as you are first loading it.

I mean for this issue, #159, to be about the time it takes to draw each frame.

[pmer]

This issue applies to all areas with a width or height larger than the viewport, so that the viewport has to scroll the area.

Right now, we run the following code on every tile in the area:

tile = tilemap.layers[l].tiles[t]
Driftwood.frame.copy(tile, ...)

However, we actually know in advance that any tile outside the viewport will not appear onscreen, so we can skip calling copy() in those cases.

One should be able to compute the left-most, right-most, top-most, and bottom-most position of tiles that can appear onscreen and only call copy() on them.

---

If a viewport is 10x10 tiles, we only need 100 calls to copy() per frame. (A few more than 100 if we are currently scrolling between tiles.) In an area that is 30x30 tiles, that saves 900 - 100 = 800 calls to copy() each frame, or 89% of the calls. The larger the area, the more significant the savings.

[pmer]

Ah, I suppose this could be called graphical occlusion?

[seisatsu]

Would you like to work on this one?

Also I misunderstood what you were saying in #157, that's not really occlusion related. This is.

[pmer]

@seisatsu Can I require that a tilemap and its associated tilesets share the same tile width and height?