I can't find blendColor() in the new reference, but it seems to work as expected under 2.0, though I haven't thoroughly tested this.

Also can't find anything about changes to it in the Changes wiki, or revisions.txt.

Has it been / is it expected to be officially deprecated, or is it a reference oversight?

If the former, what replaces it? If the latter, where is the proper place for me to log the omission?

I've got a project I'm pretty pleased with, but am now looking for some optimization.

Things work the way I want/need them to using HSB color mode. I'm doing a multi-pass pixel scan and summing the results. The main goal is to generate a static output, but there is some value in animating the result also, and in any case it would be great if I could figure out how to speed things up a bit.

I've eliminated get() and set() successfully, but am now looking at refactoring using bitwise operations. Do I need to convert to RGB first, and if so, would the extra calculations cancel out any benefits?

I'm perfectly happy to show my code, but I thought I'd start with a basic question to see if I'm totally barking up a wrong tree.

TIA,

RA

I'm trying to better understand the underlying mechanisms behind blending colors. This discussion here is informative.

Processing provides the build-in blendColor method. However, when I print the results of blended color values, and then use get() to verify, there are some discrepancies. These tend to be minor, but I'm curious as to their origin. Is it a rounding error, or is my code problematic? I have tried both BLEND and ADD modes.

Here is the test code:

1. color colorBG;  // Colors must be assigned after colorMode.
2. color color1;
3. color color2;
4. void setup() {
5.   size(200, 200);
6.   noStroke();
7.   //  colorMode(HSB);  // See if this changes things.
8.   colorBG = color(0);
9.   color1 = color(255, 10, 10, 100);
10.   color2 = color(10, 10, 255, 100);
11.  
12.   //  Using the Processing function to get the resulting color (in hex). Parameter order is important.
13.   println("Click the mouse to confirm these blended color values:\n");
14.   println("Color1 over BG color:  " + hex(blendColor(colorBG, color1, BLEND)));
15.   println("Color2 over BG color:  " + hex(blendColor(colorBG, color2, BLEND)));
16.   color color3 = blendColor(colorBG, color1, BLEND);
17.   println("Color2, Color1, BG:    " + hex(blendColor(#4E0000, color2, BLEND)));
18.   println("\n");
19. }
20. void draw() {
21.   background(colorBG);
22.   fill(color1);
23.   rect(0, 0, 150, 150);
24.   fill(color2);
25.   rect(50, 50, width, height);
26. }
27. void mousePressed() {
28.   println("Mouse location color:  " + hex(get(mouseX, mouseY)));
29. }

This may be something well known, but I'm just now bumping into it. I've searched the reference and forum however, and am not seeing it. Will happily delete the question if it's a duplicate.

Why does P3D not allow for an alpha channel when using point()? Or is it supposed to, but doesn't on some systems? Is it a Processing thing, or a hardware thing, or what?

All other modes work as expected. Test code below confirms P3D shows a black point over the white one, when it should be invisible (as it indeed is in all other modes).

1. import processing.opengl.*;
2. //size(100, 100);
3. //size(100, 100, JAVA2D);
4. //size(100, 100, P2D);
5. size(100, 100, P3D);
6. //size(100, 100, OPENGL);
7. stroke(255);
8. point(width/2, height/2);
9. stroke(0, 0);
10. point(width/2, height/2);

1. int x = 0; int y;
2. void draw() {      // Proxy draw stuff here for debugging feedback.
   
3. noStroke();
4. rect(0, 0, width, height);
5. stroke(0);
6. y = height/2;
7. ellipse(x, y, 4, 4);
8. x++;
9. x = x % width;
10. }
11. 
    
12. void keyPressed() {
13.   // Load Preferences.
14.   if (key == RETURN || key == ENTER) {
15.     String getPrefs = selectInput();
16.     if (getPrefs != null) {
17.         String[] validatesPMT = match(getPrefs, "pmt_");  // Validate file prefix.
18.         String[] validatesTXT = match(getPrefs, ".txt");  // Validate file suffix.
19.       if (validatesPMT != null && validatesTXT != null) {
20.         String[] readPrefs = loadStrings(getPrefs);
21.         int foo = int(readPrefs[0]);
22.         // array [etc.]
23.       }
24.       else println("Please make sure the file you are selecting begins with \"pmt_\" and ends with \".txt.\"");
25.     }
26.     else println("No file was selected.");
27.   }
28. } 

This question is related to, but different from what is discussed here.

If random() or noise() are not called in conjunction with randomSeed() or noiseSeed(), is there still a seed value at work behind the scenes? One that gets changed with each call? Or is the seedless process somehow completely different from the seeded one?

More to the point, if I'm playing with a non-seeded random or noisy sketch, I expect to get different results each time. But if I happen across a result that is particularly interesting, is there any way reproduce that result after the fact? That is, could some code be added which tracks how a random or noisy function got its start?

I do realize I could set a seed value from the get-go (even a randomized seed value), and print that to the console, so I'd know what seed had produced a given result. I was just wondering if there were any way to excavate the seed or genesis or ur-condition of random or noise without an explicitly specified seed. TIA.

Is this possible?

For example, using Shiffman's 1D Perlin case below, how would I initialize the ellipse to always start in the middle of the window at runtime, and then smoothly proceed with its Perlin perambulations?

1. float xoff = 0.0;
2. float xincrement = 0.01;
3. void setup() {
4.   size(200,200);
5.   background(0);
6.   frameRate(30);
7.   smooth();
8.   noStroke();
9. }
10. void draw()
11. {
12.   // Create an alpha blended background
13.   fill(0, 10);
14.   rect(0,0,width,height);
15.  
16.   //float n = random(0,width);  // Try this line instead of noise
17.  
18.   // Get a noise value based on xoff and scale it according to the window's width
19.   float n = noise(xoff)*width;
20.  
21.   // With each cycle, increment xoff
22.   xoff += xincrement;
23.  
24.   // Draw the ellipse at the value produced by perlin noise
25.   fill(200);
26.   ellipse(n,height/2,16,16);
27. }