 |
Author |
Topic: Porting to java (I'm desperate) (Read 325 times) |
|
spectre_240sx
|
Porting to java (I'm desperate)
« on: Apr 22nd, 2004, 1:04am » |
|
Ok, I know that there are people here that know java, and I do apologize for posting here, because this isn't a java forum. However, everywhere else that deals with java is all about worgroup software, etc. No-one seems to know anything about graphics, etc, and I have a project that I need done by Friday to get it into the school's final show.
At any rate, I'm having trouble figuring out how to use the Java graphics libraries. In processing I've been drawing elipses via a method inside an object class. I can't figure out how to do it in java and it seems as though there are no real object oriented applets out there to view the source for. They all just have it painting via:
Code:| public void Paint(Graphics g){} |
|
That won't work inside the method which I want to call, so I tried doing this:
Code:
public void mtdDrawAnt() {
Graphics g;
g.setColor(Color.black);
g.fillOval(posX, posY, Size, Size);
}
|
|
That plainly tells me that I haven't initialized G. Isn't that what line 2 does though?
Anyway, I'm absolutely stuck here. If anyone can offer any suggestions I'd be eternally grateful. If not, I'll understand.
Thanks,
Brian
|
|
|
|
|
amoeba
|
Re: Porting to java (I'm desperate)
« Reply #1 on: Apr 22nd, 2004, 3:15am » |
|
All applets and Java AWT components use a paint(Graphics g) function to do their drawing. Processing does too, except it's been overridden to call loop() and hide all the messy things from you.
Lookin at code I've used for combining Processing graphics with normal Java drawing, I see that I've simply overriden BApplet's paint() with my own, then called BApplet's paint() with a call to super.paint() and then done whatever drawing I have left.
Roughly speaking, this should work:
Code:void loop() {
// draw whatever
}
public void paint(Graphics g) {
super.paint(g); // Calls BApplet's normal paint
g.setColor(Color.white);
g.drawString("It works!", 20,20);
g.drawRect(10,10, 100,100);
// etc...
} |
|
Keep in mind that I haven't tested it, so you might have to tweak it. Your code doesn't work because the Graphics instance is always passed to paint(). You can't just initialize an instance of Graphics. Read up on AWT if you want to get the full story.
Good luck!
|
| « Last Edit: Apr 22nd, 2004, 3:18am by amoeba » |
|
marius watz // amoeba
http://processing.unlekker.net/
|
|
|
spectre_240sx
|
Re: Porting to java (I'm desperate)
« Reply #2 on: Apr 22nd, 2004, 4:49am » |
|
Sweet, thanks for the help. I'm going to do some major research on awt and see what I can come up with. I've found an applet (with source code) that makes objects paint themselves, so that's helped a little bit, but I've got lot of work ahead of me. 
Thanks again!
|
|
|
|
|
amoeba
|
Re: Porting to java (I'm desperate)
« Reply #3 on: Apr 22nd, 2004, 1:12pm » |
|
Just tested my code to see if it works - which it does. However you'll notice that there is flickering in the AWT part of the graphics. This is due to the fact that the Processing graphics is double-buffered and the AWT graphics are not.
The obvious way to resolve that is to set up double-buffering for your own purposes, as follows:
Code:Graphics backGraphics;
Image backBuffer;
void setup() {
size(400,400);
}
void loop() {
background(200,0,0);
fill(255);
rect(random(width),random(height),20,20);
}
public void paint(Graphics g) {
if (backGraphics == null) {
backBuffer = createImage(getSize().width, getSize().height);
backGraphics = backBuffer.getGraphics();
}
else {
super.paint(backGraphics); // Calls BApplet's normal paint
backGraphics.setColor(Color.white);
backGraphics.drawString("It works!", 20,20);
backGraphics.drawRect(10,10, 100,100);
// etc...
g.drawImage(backBuffer, 0, 0, this);
}
} |
|
However, the problem now is that Processing will give a compiler error about java.awt.Image not being assignable to BImage. The reason for this, as Ben explains in this post, is that Processing substitutes "Image" with "BImage" in preprocessing. I tried changing the pde.properties file as he says to do, but I still get the error. Any of the Processing crew want to explain this
Your best and possibly final option if you're hell-bent on doing this would be to take your project out of the Processing environment and into a full-blown Java tool like Eclipse. Toxi has outlined that process here.
|
| « Last Edit: Apr 22nd, 2004, 1:17pm by amoeba » |
|
marius watz // amoeba
http://processing.unlekker.net/
|
|
|
spectre_240sx
|
Re: Porting to java (I'm desperate)
« Reply #4 on: Apr 23rd, 2004, 6:29pm » |
|
It's funny that you mention that, because I've actually been using eclipse the whole time . That explains why I was confused at seeing "void loop{}" in java code.
Ok, this has been pretty helpful, mostly the part about double buffering. Thanks again for all your help.
|
|
|
|
|
|
