eessppeelllloo/processing4
1
0
Fork 0
mirror of https://github.com/processing/processing4.git synced 2026-06-16 04:26:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

fix the memory thing, fix create font, more simon lighting stuff

Browse Source
This commit is contained in:
benfry
2005-04-18 21:07:14 +00:00
parent 57ea2eeb11
commit 062a670294
7 changed files with 191 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
app/tools/CreateFont.java
+1 -1
View File
@@ -415,7 +415,7 @@ public class CreateFont extends JFrame {
// make sure the 'data' folder exists
if (!targetFolder.exists()) targetFolder.mkdirs();
f.write(new FileOutputStream(new File(targetFolder, filename)));
f.save(new FileOutputStream(new File(targetFolder, filename)));
} catch (IOException e) {
JOptionPane.showMessageDialog(this,
core/PConstants.java
+14 -4
View File
@@ -30,6 +30,10 @@ import java.awt.event.KeyEvent;
/**
* Numbers shared throughout processing.core.
* <P>
* An attempt is made to keep the constants as short/non-verbose
* as possible. For instance, the constant is TIFF instead of
* FILE_TYPE_TIFF. We'll do this as long as we can get away with it.
*/
public interface PConstants {
@@ -386,8 +390,14 @@ public interface PConstants {
static final int TRIANGLE_COLOR_COUNT = 8;
// normal modes for lighting
static final int AUTO_NORMAL = 0; // normal calculated per triangle
static final int MANUAL_SHAPE_NORMAL = 1; // one normal manually specified per shape
static final int MANUAL_VERTEX_NORMAL = 2; // normals specified for each shape vertex
// normal modes for lighting, these have the uglier naming
// because the constants are never seen by users
/// normal calculated per triangle
static final int AUTO_NORMAL = 0;
/// one normal manually specified per shape
static final int MANUAL_SHAPE_NORMAL = 1;
/// normals specified for each shape vertex
static final int MANUAL_VERTEX_NORMAL = 2;
}
core/PFont.java
+13 -6
View File
@@ -116,6 +116,7 @@ public class PFont implements PConstants {
//int numBits = is.readInt();
// used to be the bitCount, but now used for version number.
// version 8 is any font before 69, so 9 is anything from 83+
// 9 was buggy so gonna increment to 10.
int version = is.readInt();
// this was formerly ignored, now it's the actual font size
@@ -212,7 +213,7 @@ public class PFont implements PConstants {
//System.out.println();
}
if (version == 9) { // includes the font name at the end of the file
if (version == 10) { // includes the font name at the end of the file
name = is.readUTF();
psname = is.readUTF();
}
@@ -220,16 +221,21 @@ public class PFont implements PConstants {
/**
* Write this PFont to an OutputStream. It is assumed that the
* calling class will handle closing the stream when finished.
* Write this PFont to an OutputStream.
* <p>
* This is used by the Create Font tool, or whatever anyone else dreams
* up for messing with fonts themselves.
* <p>
* It is assumed that the calling class will handle closing
* the stream when finished.
*/
public void write(OutputStream output) throws IOException {
public void save(OutputStream output) throws IOException {
DataOutputStream os = new DataOutputStream(output);
os.writeInt(charCount);
// formerly numBits, now used for version number
os.writeInt((name != null) ? 9 : 8);
os.writeInt((name != null) ? 10 : 8);
os.writeInt(size); // formerly mboxX (was 64, now 48)
os.writeInt(mbox2); // formerly mboxY (was 64, still 64)
@@ -254,8 +260,9 @@ public class PFont implements PConstants {
}
}
if (name != null) { // version 9
if (name != null) { // version 10
os.writeUTF(name);
os.writeUTF(psname);
}
os.flush();
core/PGraphics3.java
+121 -3
View File
@@ -3468,9 +3468,127 @@ public class PGraphics3 extends PGraphics {
/**
* Sets up an ambient and directional light.
* <P>
* The directional light is setup second, so that it can be modified
* via lightSpecular() or lightFalloff() if needed.
* <PRE>
* The Lighting Skinny:
*
* The way lighting works is complicated enough that it's worth
* producing a document to describe it. Lighting calculations proceed
* pretty much exactly as described in the OpenGL red book.
*
* Light-affecting material properties:
*
* AMBIENT COLOR
* - multiplies by light's ambient component
* - for believability this should match diffuse color
*
* DIFFUSE COLOR
* - multiplies by light's diffuse component
*
* SPECULAR COLOR
* - multiplies by light's specular component
* - usually less colored than diffuse/ambient
*
* SHININESS
* - the concentration of specular effect
* - this should be set pretty high (20-50) to see really
* noticeable specularity
*
* EMISSIVE COLOR
* - constant additive color effect
*
* Light types:
*
* AMBIENT
* - one color
* - no specular color
* - no direction
* - may have falloff (constant, linear, and quadratic)
* - may have position (which matters in non-constant falloff case)
* - multiplies by a material's ambient reflection
*
* DIRECTIONAL
* - has diffuse color
* - has specular color
* - has direction
* - no position
* - no falloff
* - multiplies by a material's diffuse and specular reflections
*
* POINT
* - has diffuse color
* - has specular color
* - has position
* - no direction
* - may have falloff (constant, linear, and quadratic)
* - multiplies by a material's diffuse and specular reflections
*
* SPOT
* - has diffuse color
* - has specular color
* - has position
* - has direction
* - has cone angle (set to half the total cone angle)
* - has concentration value
* - may have falloff (constant, linear, and quadratic)
* - multiplies by a material's diffuse and specular reflections
*
* Normal modes:
*
* All of the primitives (rect, box, sphere, etc.) have their normals
* set nicely. During beginShape/endShape normals can be set by the user.
*
* AUTO-NORMAL
* - if no normal is set during the shape, we are in auto-normal mode
* - auto-normal calculates one normal per triangle (face-normal mode)
*
* SHAPE-NORMAL
* - if one normal is set during the shape, it will be used for
* all vertices
*
* VERTEX-NORMAL
* - if multiple normals are set, each normal applies to
* subsequent vertices
* - (except for the first one, which applies to previous
* and subsequent vertices)
*
* Efficiency consequences:
*
* There is a major efficiency consequence of position-dependent
* lighting calculations per vertex. (See below for determining
* whether lighting is vertex position-dependent.) If there is no
* position dependency then the only factors that affect the lighting
* contribution per vertex are its colors and its normal.
* There is a major efficiency win if
*
* 1) lighting is not position dependent
* 2) we are in AUTO-NORMAL or SHAPE-NORMAL mode
*
* because then we can calculate one lighting contribution per shape
* (SHAPE-NORMAL) or per triangle (AUTO-NORMAL) and simply multiply it
* into the vertex colors. The converse is our worst-case performance when
*
* 1) lighting is position dependent
* 2) we are in AUTO-NORMAL mode
*
* because then we must calculate lighting per-face * per-vertex.
* Each vertex has a different lighting contribution per face in
* which it appears. Yuck.
*
* Determining vertex position dependency:
*
* If any of the following factors are TRUE then lighting is
* vertex position dependent:
*
* 1) Any lights uses non-constant falloff
* 2) There are any point or spot lights
* 3) There is a light with specular color AND there is a
* material with specular color
*
* So worth noting is that default lighting (a no-falloff ambient
* and a directional without specularity) is not position-dependent.
* We should capitalize.
*
* Simon Greenwold, April 2005
*/
public void lights() {
// need to make sure colorMode is RGB 255 here
core/todo.txt
+3
View File
@@ -1,4 +1,7 @@
0084 core
X fixed create font / incremented font file version number
X simon lighting fixes
X added simon's lighting docs to lights() fxn in javadoc
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
net/Client.java
+3 -1
View File
@@ -129,6 +129,7 @@ public class Client implements Runnable {
} catch (Exception e) {
e.printStackTrace();
}
thread = null;
input = null;
output = null;
@@ -145,7 +146,8 @@ public class Client implements Runnable {
public void run() {
while (Thread.currentThread() == thread) {
try {
while (input.available() > 0) { // this will block
while ((input != null) &&
(input.available() > 0)) { // this will block
synchronized (buffer) {
if (bufferLast == buffer.length) {
byte temp[] = new byte[bufferLast << 1];
todo.txt
+36 -16
View File
@@ -2,30 +2,39 @@
X can't edit prefs while processing is open, remove the link
X add run.options for things run externally
X load options via vector because they need to be split up
X stability improvements to processing.exe from simon
X memory on external apps is a little broken
pending
_ rename video.Camera to video.Video ?
_ rename video.Camera to video.Video ? Capture ?
_ VideoInput VideoOutput, SoundInput, SoundOutput or AudioInput/AudioOutput
_ casey stuff
_ new bboard? archive the old one, remove bugs sections
_ environment reference
_ list of changes since rev 69? run through revisions.txt
_ need to straighten out for when audio comes along
_ check for updates should happen only daily or weekly
_ list of changes since rev 69? run through revisions.txt
_ setup bugzilla and enter all the bugs
_ create font is somewhat broken
_ memory on external apps is a little broken
_ update the message sent to people who sign up for the list
_ change success message to read
_ your email has been received successfully, you'll be receiving
_
//
SAVE AS BUGS
"SAVE AS..." BUGS
Minor issue, but caused me a couple seconds of confusion. If you rename your sketch then try to close the application without saving first, it asks you if you want to save but mentions the pre-rename name. But I hit yes, quit, came back in, and all seemed right in the world.
Minor issue, but caused me a couple seconds of confusion. If you
rename your sketch then try to close the application without saving
first, it asks you if you want to save but mentions the pre-rename
name. But I hit yes, quit, came back in, and all seemed right in the
world.
Is it possible that saving with the 'save' button doesn't pay attention to where you point at the project folder from prefs? Jeez, i phrased that horribly. I opened preferences for Processing and made the default sketchbook location processing-0079/projects. I then put all my older projects in that project folder. When i opened up an old file and made changes, i then hit 'save' and quit. I relaunched v79 and opened the aforementioned file, and none of the changes were there. but they were in v77 project folder.
Is it possible that saving with the 'save' button doesn't pay
attention to where you point at the project folder from prefs? Jeez,
i phrased that horribly. I opened preferences for Processing and made
the default sketchbook location processing-0079/projects. I then put
all my older projects in that project folder. When i opened up an old
file and made changes, i then hit 'save' and quit. I relaunched v79
and opened the aforementioned file, and none of the changes were
there. but they were in v77 project folder.
create a new sketch
create a new tab named "a"
@@ -36,7 +45,10 @@ unhide "a_2"
unhide "a"
where did "a_2" go ?
(v74) if a project folder is made (with save as), and then deleted while processing is still open, there is an error (of course). but the error ('file/folder not found') is not displayed to the user, and the drop-downs don't go away / the IDE doesn't refresh.
(v74) if a project folder is made (with save as), and then deleted
while processing is still open, there is an error (of course). but
the error ('file/folder not found') is not displayed to the user,
and the drop-downs don't go away / the IDE doesn't refresh.
(74) "save as" not actually saving properly
File>New
@@ -50,7 +62,11 @@ can tell, is to Save As once, make at least one change, then Save.
what happens if folder already exists on save as?
saving a project over an already existing project does not get rid of the .pde files that arent overwritten. not sure if this is feature or bug, but it took me by surprise. it seemed to only overwrite .pde files with the same name, but everything else in that project folder stays as is.
saving a project over an already existing project does not get rid of
the .pde files that arent overwritten. not sure if this is feature or
bug, but it took me by surprise. it seemed to only overwrite .pde
files with the same name, but everything else in that project folder
stays as is.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@@ -58,6 +74,10 @@ saving a project over an already existing project does not get rid of the .pde f
NOT NECESSARY BEFORE BETA
_ check for updates should happen only daily or weekly
_ setup bugzilla and enter all the bugs
_ placement of 100x100 items is odd
_ happens with P3D and maybe also P2D?