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 › Programming Questions & Help › Syntax Questions › Is this a problem with scale()
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: 1
Is this a problem with scale() ? (Read 910 times)
crispin
Is this a problem with scale() ?
Nov 12th, 2007, 5:52pm  
Hi,

I noticed that when using 'scale', there is a tendency for the relationship between objects (e.g. rect, image, etc...) to be off by a pixel or so.  I was wondering if this may have something to do with the position/dimensions of the objects not being 'rounded-off' nicely (i.e. 43.2 = 43 pixels, 56.6 = 57 pixels).  Perhaps Processing is just dropping the decimal point?

Cheers,
Crispin
Back to top
 
 
fry
Re: Is this a problem with scale() ?
Reply #1 - Nov 13th, 2007, 11:32am  
i assume you're using P3D, which is fast but not accurate. i've added an extra line to the size() reference to explicitly state that.
Back to top
 
WWW  
mflux
Re: Is this a problem with scale() ?
Reply #2 - Nov 13th, 2007, 7:59pm  
Hi Ben

Out of curiosity, is this somehow something to do with P3D's inability for smooth()?

~M
Back to top
 
Portfolio
fluxhavoc  
crispin
Re: Is this a problem with scale() ?
Reply #3 - Nov 13th, 2007, 10:54pm  
Hi,

Actually, I'm using OPENGL (no smooth() ). Like I said, it's not MAJOR, but enough to throw a border out of line.

Also, on an unrelated note:
for some reason frame.setDefaultCloseOperation() doesn't work in Processing.  I have tried using it in setup() beside other frame commands, like setTitle() and WindowListeners (which work fine), but it says that it can't find 'setDefaultCloseOperation'...  I  need to set it to 'do nothing on exit' so that I can poll the user to save their work.

Cheers,
Crispin
Back to top
« Last Edit: Nov 20th, 2007, 5:15pm by crispin »  
 
crispin
Re: Is this a problem with scale() ?
Reply #4 - Nov 20th, 2007, 5:15pm  
bump -

Hi,

Actually, I'm using OPENGL (no smooth() ). Like I said, it's not MAJOR, but enough to throw a border out of line.

Also, on an unrelated note:  
for some reason frame.setDefaultCloseOperation() doesn't work in Processing.  I have tried using it in setup() beside other frame commands, like setTitle() and WindowListeners (which work fine), but it says that it can't find 'setDefaultCloseOperation'...  I  need to set it to 'do nothing on exit' so that I can poll the user to save their work.  

Cheers,
Crispin
Back to top
 
 
fry
Re: Is this a problem with scale() ?
Reply #5 - Nov 21st, 2007, 2:22pm  
3D renderers are generally not made to do pixel accurate graphics.

setDefaultXxxx() is not a method of Frame, which is what the sketch is placed into. read http://processing.org/faq.html#java and the developer's reference for PApplet.
Back to top
 
WWW  
crispin
Re: Is this a problem with scale() ?
Reply #6 - Nov 23rd, 2007, 10:44pm  
>>3D renderers are generally not made to do pixel accurate >>graphics.  

Hmm... It might be a silly question, but is there any way that I can get pixel accurate graphics?  I'm not trying to play Quake, I just wan't my GUI to be pretty Wink

>>setDefaultXxxx() is not a method of Frame, which is what >>the sketch is placed into. read >>http://processing.org/faq.html#java and the developer's >>reference for PApplet.

Ok, I was getting JFrame and Frame confused...

On a side note, I really needed to use 'open file' dialogs within my program, so I did so using swing.  So long as I open them from within another thread, it doesn't [seem] to cause any problems.  Am I unknowingly screwing myself here?

Thanks Ben

Crispin
Back to top
 
 
Page Index Toggle Pages: 1
‹ Previous Topic | Next Topic ›