08-19-2023, 04:28 PM
Hi!
There are two things that kill performance on a CPU: branching (i.e. conditionals) and scattered memory fetches. Writing a pixel -that is, writing a memory location- is way more cheaper. So it's much more efficient to do a bit of overdraw but reduce the number of branching and memory reads. Working per-pixel requires lots of test conditions and reads from differents sources until the final pixel value is determined. On the other hand, once the start addresses of the items are determined, the pixels of the item are outputted in a row with very little branching, and with high cache coherence: as the source pixels are adjacent in memory, chances of being already cached are much higher than doing scattered reads. This is at the cost of a bit of overdraw, but as you have found yourself, this is much more efficient in terms of performance.
I store the scanlines of tilesets sequentially:
There are two things that kill performance on a CPU: branching (i.e. conditionals) and scattered memory fetches. Writing a pixel -that is, writing a memory location- is way more cheaper. So it's much more efficient to do a bit of overdraw but reduce the number of branching and memory reads. Working per-pixel requires lots of test conditions and reads from differents sources until the final pixel value is determined. On the other hand, once the start addresses of the items are determined, the pixels of the item are outputted in a row with very little branching, and with high cache coherence: as the source pixels are adjacent in memory, chances of being already cached are much higher than doing scattered reads. This is at the cost of a bit of overdraw, but as you have found yourself, this is much more efficient in terms of performance.
I store the scanlines of tilesets sequentially:
- 1st row of tile 0
- 2nd row of tile 0
- ...
- nth row of tile 0
- 1st row of tile 1
- 2nd row of tile 1
- ...
- nth row of tile 1