HPMANLe 18/09/2016 à 07:41
Here's a little something I've been toying with.
The issue:
Considering a large scroll section, like the following:
Current tools work out the palettes to the best of their ability, but palettes count can quickly rise to large numbers. As they have to sit in palette RAM, it can be a problem to have room left for other elements.
Above example end up taking 228 palettes.
The solution:
We know a scroller displays max 21 sprites, so the solution is to rework the tilemap and add a palette management to move palettes in/out the palette RAM depending on requirements for currently displayed data.
So instead of having to reserve 228 palettes, you shrink palettes usage to the highest count required at any time.
For the above example we shrink down from 228 to 71 palettes:
The solution is fairly light on CPU, takes up some more ROM space, but it is a good trade off for more palettes RAM ressources.
And it actually works
The issue:
Considering a large scroll section, like the following:
Current tools work out the palettes to the best of their ability, but palettes count can quickly rise to large numbers. As they have to sit in palette RAM, it can be a problem to have room left for other elements.
Above example end up taking 228 palettes.
The solution:
We know a scroller displays max 21 sprites, so the solution is to rework the tilemap and add a palette management to move palettes in/out the palette RAM depending on requirements for currently displayed data.
So instead of having to reserve 228 palettes, you shrink palettes usage to the highest count required at any time.
For the above example we shrink down from 228 to 71 palettes:
The solution is fairly light on CPU, takes up some more ROM space, but it is a good trade off for more palettes RAM ressources.
And it actually works
