0

I found that formula of SDL_SetTextureColorMod is srcC = srcC * (color / 255). But what happens when (color / 255) is not a int. I do not understand how it wokrs. PLease help me.

  • I think you are confused about what that formula is. You don't use it, SDL does. What you provide as r, g, and b to SDL_SetTextureColorMod are coefficients. Instead of being from 0 to 1, they are from 0 to 255. That's all. – Nelfeal Feb 23 '23 at 16:21

2 Answers2

1

When (color / 255) is not an int, the resulting color value will be a decimal number, which will be rounded down to the nearest integer before being assigned to the pixel.

CloudySh
  • 11
  • 2
  • But it doesn't seem to work. I used [`SDL_GetTextureColorMod`](https://wiki.libsdl.org/SDL2/SDL_GetTextureColorMod) to print current color. This [code](https://lazyfoo.net/tutorials/SDL/12_color_modulation/index.php) from lazyfoo tutorial can set the correct color to (r,g,b) without following the formula. – hoangquocvietuet Feb 23 '23 at 11:06
0

It modifies the value of each color channel according to the formula.

Notice the important words "according to formula".

This means that it will do "something" to the data that you can predict with that formula.

At the end of the day, it can be some bit shifting, xoring who knows what magic that achieves the same result when used with values from 0-255.

As you pointed out, even when calculating this on paper, the whole formula srcC = srcC * (color / 255) may not end up being an integer. In that case, it is most likely that there is some rounding going on.

In most cases, it is a custom to delay the floating point arithmetics as much as possible (in terms of coming up with an algorithm, not at runtime) so that we may actually calculate something this: srcC = (srcC * color) / 255 at wich point the only error is how we round that to integer. C and C++ do this by just "cutting off" the numbers after the decimal point. (a.k.a. floor)

on the other hand if there was something like this written in the code int srcC = srcC * (color / (float)255) it would calculate the value with floating point arithmetics (with decimal points included), but that can lead to rounding errors (I'm quite sure that values from 0 to 255 would not lead to them in such simple formula) because you first represent the color/255 as a floating point which can cause rounding (imagine it like 1/3 in decimal, you end up with infinite ammount of 0.333333... but you can only store so many digits) and then this potentially imprecise value is multiplied, making the error larger and then potentially rounding it again. and then it gets round it to integer during the assignment. (Floating point is quite clever and does achieve an impressive precision if used properly, but it may bite you missused especially if you'd want to calculate some geometry problem for example)

Another thing about floating point arithmetic is, that it is quite slow in comparison to integer arithmetic. It's no coincidence that supercomputers' power is messured in FLOPs.