bug: [deco] color picker

  • BuysDB
    8th Apr 2012 Member 0 Permalink
    Color picked by middle click is darker than the actual color, which is pretty annoying.

  • Simon
    8th Apr 2012 Administrator 0 Permalink
    It seems to be caused by rounding the decoration values when rendering the scene, since the sample tool actually samples the on-screen buffer rather than the deco-colour of the particle, it inherits the issue from rendering. I don't see any point fixing this, since it's a performance optimisation causing the issue.
  • jacob1
    8th Apr 2012 Developer 0 Permalink
    @Simon (View Post)
    Actually, it looks like the r, g, and b values just decrease by 1 every time no matter what, so it's not a rounding problem. If for example r is 1, or it's 255, when you sample it you'll get 0 and 254, so adding 1 to each will fix it.
  • jacksonmj
    8th Apr 2012 Developer 0 Permalink
    The problem is the ">> 8", used instead of "/ 255" when blending colours in render_parts (and other places, but render_parts is the function causing this particular problem). ">> 8" is equivalent to dividing by 256.

    The maximum alpha value (cola, deca, firea) is 255.
    255 >> 8 = 255 / 256 which is less than 1, rounding error occurs, and the resulting RGB values are slightly too small.

    Changing ">> 8" to "/ 255" does fix the issue, but I haven't tested what the impact on performance is.
  • jacob1
    9th Apr 2012 Developer 0 Permalink
    Even, if there is rounding error, I found out that it's always the same, so you can just add 1 to each color value as long as its not 0, and that will mostly fix it except for when r, g, or b is 1. There's no need to change all those if this way is easier.
  • epicksl
    9th Apr 2012 Member 0 Permalink
    **epicksl nods and pretends to understand what jacksonmj said**
  • baizuo
    9th Apr 2012 Member 0 Permalink
    But >>8 is faster than /255
    While human eyes can hardly notice only 1 gray scale