tepples wrote:
And because division by 256 is so fast, games will scale things by multiplying by a fraction 1/256 through 255/256 by first multiplying by 1 through 255 and then dividing by 256
I didn't realize that, and after a small adjustment the difference is now notable. I could not think the float/int difference would be that high. Now i find my self looking at places where to apply this optimization.
adam_smasher wrote:
The SNES has a screen brightness register; that's what most games would probably used to darken the screen.
But i guess that at some point you have to apply the brightness anyway.
tepples wrote:
Games change just 256 values (the palette), and everything else on the screen refers to that palette.
adam_smasher wrote:
Nevertheless, the idea is the same: the emulator precomputes the darkened palette and uses it to draw the screen rather than doing a floating point multiply on each pixel after-the-fact.
This makes a lot of sense, i count the number of colors on the picture above and is roughly 100, very low and common in pixel art. Having to process just 100 is a lot faster than computing each pixel. But thinking about it, might be nightmarish to apply transparency, isn't it? I imagine the workflow to be:
Code:
for each color in palette2:
if it exists in palette1: update index in image 2
else: add new color and update index in image 2
for each pixel in image2:
copy index to image1

Now, if you have to take into account the new colors produced by alpha blending, having to locate every new color (probably it didn't exist before) can be a slow operation.
Also, does the snes emply a different palette for every sprite/tile?