We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
Index › Processing Development › Core,  Processing Development Environment (PDE) › PImage methods vs. (display window) functions
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: 1
PImage methods vs. (display window?) functions (Read 2218 times)
Ira
PImage methods vs. (display window?) functions
Jan 22nd, 2006, 5:41pm  
Man am I finding it hard to write about PImage functions/methods. The similiar functionality and common names(img.blend() vs. blend()) has got to be baffling to new users, especially since there's usually a PImage or 2 involved in the function calls. Might it be better to simply eliminate method approach altogether (or at least pull it out of the referece,) and keep calls procedurally consistent with rest of Processing? Or am I missing something. I've been spending waaay too much time deciphering toxi's PImage bitwise bonanza.

ira
Back to top
 
Processing: Creative Coding and Computational Art
http://friendsofed.com/book.html?isbn=159059617X

The Essential Guide to Processing for Flash Developers
http://www.friendsofed.com/book.html?isbn=9781430219798

Center of Creative Computation
Meadows/Lyle
SMU, Dallas
WWW irarobinian  
JohnG
Re: PImage methods vs. (display window?) functions
Reply #1 - Jan 22nd, 2006, 10:11pm  
I think the difference is that if it's a method, it somehow changes the object that it's a method of.
If it's a global function, it doesn't change any of the objects passed in.
Back to top
 
 
Ira
Re: PImage methods vs. (display window?) functions
Reply #2 - Jan 23rd, 2006, 12:02am  
Thanks John,
My question is more pedagogical in nature, with regard to structure/usability of Processing language.
ig
Back to top
« Last Edit: Jan 23rd, 2006, 4:56am by Ira »  
Processing: Creative Coding and Computational Art
http://friendsofed.com/book.html?isbn=159059617X

The Essential Guide to Processing for Flash Developers
http://www.friendsofed.com/book.html?isbn=9781430219798

Center of Creative Computation
Meadows/Lyle
SMU, Dallas
WWW irarobinian  
Ricard
Re: PImage methods vs. (display window?) functions
Reply #3 - Jan 23rd, 2006, 1:58am  
from my perspective:

In order to make Processing be usable from an "procedural" and in an "object oriented" point of view.  It's programed in some how with default instances of classes.

This means that when you you want to draw a line, you don't need to create a class PGraphics and call it's method line(), processing has already created the default class called "g".

I think this can be applied to PImage, but I'm not sure there's a default class.

I think that all this is more of my point of view than what it really is in the code, haven't looked in detail.

Anyway a thought, for Processing 2.0 (if this wasn't the case), it would be nice that this idea could be applied to all kind of objects.  Like that you could really take an object oriented (OO) approach from any procedural part that has been done.

So that when you apply beginShape() processing creates an object PShape that could be called poly[0].  Like that later on you can (from an OO point of view) access it and modify it.

What do you think about this latenight thought?
Back to top
 
WWW  
fry
Re: PImage methods vs. (display window?) functions
Reply #4 - Jan 23rd, 2006, 3:26pm  
ira, i agree this is an ugly setup.. the problem is that we're a ways from having a blendMode() method that would make such a setup obselete, so we used toxi's implementation as it was.

PGraphics subclasses PImage, which creates some confusion, because it means that a PGraphics object is just a pixel buffer like any other. right now we're not taking great advantage of this, but it will improve.

we've tried to be consistent with how blend acts on things (just keep in mind that if an image isn't specified, it's using the main drawing surface as an image), but it's a bit abstract.
Back to top
 
WWW  
Page Index Toggle Pages: 1
‹ Previous Topic | Next Topic ›