 |
Author |
Topic: java.awt.Image vs. BImage (Read 630 times) |
|
amoeba
|
java.awt.Image vs. BImage
« on: Dec 8th, 2003, 7:16pm » |
|
Am I right in thinking that the Processing preprocessor changes all references to "Image" to "BImage", thereby breaking references to java.awt.Image? The following code will give you double-buffering if compiled with a Java compiler using Processing as a library, but in Processing it won't compile because Image suddenly becomes BImage.
It's not really a problem for me, since I'm using it in a full Java environment, but I thought I'd contribute some simple code for combining P5 graphics with standard AWT graphics.
Is there is an easy way to double-buffer in Processing itself, so that you could have non-clearing rendering (i.e. trails etc.) combined with elements that do clear every frame (i.e. interface etc)? that'd be a nice way to do fast rendering while keeping specific elements sharp and clean...
I assume the frame gets written to pixels[] after loop() is done, so I don't see a way to store a copy of pixels[] at a certain state, then rendering certain elements on top of it, drawing that to the screen and restoring pixels[] before the next frame so that those elements don't get permanently drawn onto the frame.
Hmm, I'm not being too clear, but maybe someone understands what I'm getting at...
Code:import java.awt.Image;
public class doubleBuffer extends BApplet {
java.awt.Graphics backGraphics;
java.awt.Image backBuffer;
public void init() {
super.init();
backBuffer=createImage(width,height);
backGraphics=backBuffer.getGraphics();
}
void setup() {
size(400,400);
background(200,200,255);
ellipseMode(CENTER_DIAMETER);
noStroke();
smooth();
}
void loop() {
fill(50,50,150, 100);
ellipse(random(width),random(height), 30,30);
fill(255,255,255, 100);
ellipse(random(width),random(height), 10,10);
}
public void paint(Graphics graph) {
super.paint(backGraphics);
backGraphics.setColor(new Color(255,255,255));
backGraphics.drawString("Test",(int)(cnt*10)%size().width+20,20);
graph.drawImage(backBuffer,0,0,this);
}
}
|
|
|
marius watz // amoeba
http://processing.unlekker.net/
|
|
|
fry
|
Re: java.awt.Image vs. BImage
« Reply #1 on: Dec 8th, 2003, 8:09pm » |
|
on Dec 8th, 2003, 7:16pm, amoeba wrote:| Am I right in thinking that the Processing preprocessor changes all references to "Image" to "BImage", thereby breaking references to java.awt.Image The following code will give you double-buffering if compiled with a Java compiler using Processing as a library, but in Processing it won't compile because Image suddenly becomes BImage. |
|
to shut off this behavior, just add this line:
compiler.substitute_image=false
to the pde.properties file inside 'lib'.
not sure if we're gonna keep or remove this substitution, because of the problem you describe.
also, once shut off, you also have the option to construct a new BImage out of a java image by using:
BImage b = new BImage(Image someJavaImage);
|
|
|
|
|
kevinP
|
Re: java.awt.Image vs. BImage
« Reply #2 on: Feb 19th, 2004, 7:19pm » |
|
on Dec 8th, 2003, 7:16pm, amoeba wrote:The following code will give you double-buffering
|
|
Hi,
I tried this (after making the config change Ben mentions) but I get a "Type Graphics not found" error. Any suggestions
-K
|
Kevin Pfeiffer
|
|
|
justo
|
Re: java.awt.Image vs. BImage
« Reply #3 on: Feb 20th, 2004, 10:34pm » |
|
i'm not sure if i completely understand what youre asking, but you can easily make your own int array with the same length as pixels[]...or you can make your own BImage and do stuff with that...then you can just System.arraycopy() the whole thing over for double buffering or use a for loop and selectively copy/blend the new pixels in.
|
|
|
|
|
|
