What's the difference between int negative color values and float negative color values?

In fact I have two questions. 1. how does fill() interpret big negative numbers, such as "fill(-1000)"? 2. In the following examples, type int color value makes the rect change colour from white to black to yellow, while float value makes the rect change colour simply from white to black. How does that happen(fill(-1000) vs. fill(-1000.0))?

type "int" x: int x = 255; void setup(){ size(300, 300); background(0); } void draw(){ fill(x); rect(0, 0, 100, 100); x--; println(x); }

type "float" x: float x = 255; void setup(){ size(300, 300); background(0); } void draw(){ fill(x); rect(0, 0, 100, 100); x--; println(x); }

Tagged:

Answers

  • Okay, for your first question I am not so sure, I haven't tried. But for the second question, let's see, okay, an int, and you are taking away from it, in this case your int is 255, you are only going on the black to white scale. Because you only have one fill() value. Whereas with the float it is doing the same thing, but is interacting with the -1000.0 I'm thinking because the -1000.0 is more specific, and is mostly the best to use when dealing with changing objects.

  • I mean, it is best to use a float when dealing with changing variables.

  • edited February 2015

    Processing's color datatype represents a 32-bit Java's int datatype:
    https://processing.org/reference/color_datatype.html

    Processing has a complex way to determine how color parameters are interpreted:
    https://processing.org/reference/color_.html

    • Passing 1 argument, values between 0 and maxColor from colorMode() are interpreted as gray scale.
    • Otherwise it's interpreted as an ARGB value.
    • Notice that outside range values are clamped!
    • As you had noticed, when that 1 argument is float, it's always gray scale!

    For why colors happen to be in negative range many times, read these Wikipedia articles below: :-B

  • @GoToLoop:: with float and outside values, values are set to min or max and we remain in grayscale; but with int and values out of range it seems different; when max or min are exceeded colormode "changes" and some kind of cycle happens each 255 (510,1020...) with color(255,255,x) (from white to yellow). I dont understand why and cannot explain but the code below shows that better than words...

         int x = 256;
        int y = 255;
    
        void setup(){
        size(300, 300);
        background(0);
        }
        void draw(){
         frameRate(24);
         color coul = color(x);//when min value: seems to leave grayscale to cycle(each 255...510...) reached in ARGB mode (255,255,[0,255];
          fill(coul);
    
          rect(0, 0, 100, 100);
    
          fill(255,255,y);//when min value: no more change, y always == 0
          rect(0,200,100,100);
           x--;
          y--;
          println(x);
    
        }
    
  • edited February 2015

    Thanks @akenaton for the extra info. :)>-
    Although I've just focused w/ 1 parameter only for simplicity's sake! 8-X

  • @GoToLoop== yes and your answer is perfectly clear! - But till now i thought that out of r values or give unpredictible results or are automatically reset into range (or throw illegalargument exception): that is not true but remains strange!

  • edited February 2015

    Yea, very confusing! Besides corrupting result when multiple threads call them! :-@

    All those crazy calculations are done by protected colorCalc() & colorCalcARGB() functions and their multiple overloaded forms:
    https://github.com/processing/processing/blob/master/core/src/processing/core/PGraphics.java#L7210

  • Thank you everyone. It seems the deeper mechanism is more complicated than I expected. I'm not a math or programming person, so right now it's better for me to just remember the existing difference regardless of the real cause...

  • @GoToLoop=== yes, these functions seem to be the key...knowing that colorModeX ==255; as for threading i have not tried, i will; tried with HSB:: not the same results! but finally, knowing that negative or out of range values could be a problem is the good thing to know....

  • edited February 2015

    Colors in Processing are stored as:
    - Binary: AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB
    - Hexadecimal: AARRGGBB

    Where A is alpha, R is red, G is green, and B is blue

    When you use color(), fill(), etc. by default alpha is set to full. For example, color(0) in hexadecimal would be 0xff000000. It is not meant to be understood by Processing users what that value is in decimal because it doesn't matter (the value would be -16777216)

    The reason these strange looking values are created is due to how signed integers work. Behind the scenes, a color type is an int so it has 32 bits of information (4 bytes) and the last bit is used to represent the sign of the number:
    - If the last bit is a 0 then the number is positive
    - If the last bit is a 1 then the number is negative
    - Any color with full alpha will result in a negative number

    However, it doesn't matter to Processing whether these values are positive, negative, big, small, etc. All that matters is that the 4 channels can be accessed as AARRGGBB. Whatever value that is as a signed integer doesn't make a difference

    Here is a sketch to show decimal vs hexadecimal for some common colors:

    void setup() {
      size(100, 100);
    
      // White is a negative number when view in decimal (-1)
      // It makes a lot more senes in hexadecimal (0xffffffff)
      color white = color(255);
      println("White = "+white+", white hex = "+hex(white));
    
      // Red in decimal: -65536
      // In hexadecimal: 0xffff0000
      color red = color(255, 0, 0);
      println("Red = "+red+", red hex = "+hex(red));
    
      // Green decimal: -16711936
      // In hexadecimal: 0xff00ff00
      color green = color(0, 255, 0);
      println("Green = "+green+", green hex = "+hex(green));
    
      println(color(0));
    
      exit();
    }
    
Sign In or Register to comment.