FAQ
Cover
This is the archive Discourse for the Processing (ALPHA) software.
Please visit the new Processing forum for current information.

   Processing 1.0 _ALPHA_
   Discussion
   Community, Collaboration, Status
(Moderator: REAS)
   Status 11 May 2004
« Previous topic | Next topic »

Pages: 1 
   Author  Topic: Status 11 May 2004  (Read 1294 times)
fry

WWW
Status 11 May 2004
« on: May 11th, 2004, 4:31pm »

status for the software side of things..
 
i've now completed by phd dissertation and defense, and as of this week will begin having more time to work on processing. this is good. not sure how consistent the schedule will be, but it'll be better than it's been the last few months, no doubt.
 
the main thing is that i've gone back to working on the release containing big changes (multiple files, more flexible sketchbook) which unfortunately is much closer to a rewrite (or a version 2.0 before we've hit 1.0) of p5 than i would like. i'm still looking for suggestions on what to call it. i'd call it 70 but i've done that with 68 and 69 and those both turned out to be maintenance releases.
 
casey and i are planning to really get the project moving this summer. we're making our way through the paperwork for open-sourcing the project, and i'm anxious to deal with the backlog of bugs that y'all have been reporting while i've been busy.  
 
one thing that we might want to do is to have a way for people to vote on bugs and features (ala the java bug parade or other such systems) so that we have a better feel for what's really driving people nuts. i.e. would you rather have built-in postscript export or clipping planes for 3D would you rather have opengl support via jogl or a better video library (my tendency is to think that the latter is best in both cases, but we want to make sure we're in sync with how people are using/thinking about p5).
 
that's the story for now.. more developments to come..
 
previous status report for easy backtracking:
http://processing.org/discourse/yabb/board_Collaboration_action__display_num_1075833630.html
 
TomC

WWW
Re: Status 11 May 2004
« Reply #1 on: May 11th, 2004, 4:41pm »

on May 11th, 2004, 4:31pm, fry wrote:

i'm still looking for suggestions on what to call it. i'd call it 70 but i've done that with 68 and 69 and those both turned out to be maintenance releases.

 
Processing MegaBucket.
 
on May 11th, 2004, 4:31pm, fry wrote:
one thing that we might want to do is to have a way for people to vote on bugs and features (ala the java bug parade or other such systems) so that we have a better feel for what's really driving people nuts.

 
Great idea.  Can we vote for that too
 
 
ess

Email
Re: Status 11 May 2004
« Reply #2 on: May 11th, 2004, 5:10pm »

names are so passe,
 
why not name it a symbol? like this:
 
http://mywebpages.comcast.net/warptera/boards/prince.bmp
 
amoeba

WWW
Re: Status 11 May 2004
« Reply #3 on: May 11th, 2004, 10:59pm »

Ben, I look forward to seeing whatever you guys decide to do.  
 
However, I'd love to see to see the project go Open Source. As much as I realize that's going to be a lot of work, I think it would be a great boost to getting bugs fixed, new technology incorporated etc.
 
Currently I write most of my Processing work in JBuilder, and having access to the actual BApplet code etc would be a great help. It would also make it much easier to create libraries that integrate with the internal structure of Processing.  
 
I realise this might still be a way into the future, since you probably want to standardize the structure of the project, but when it happens I think it will be great.
 
(Oh, and almost all my students hate the fact that the polygon fill code is broken. But that's them...)
« Last Edit: May 11th, 2004, 11:00pm by amoeba »  

marius watz // amoeba
http://processing.unlekker.net/
fry

WWW
Re: Status 11 May 2004
« Reply #4 on: May 12th, 2004, 4:24am »

we just signed the open source paperwork, and it'll be turned in to the mit ip office as soon as it arrives in the mail from casey. with any luck, it could be as early as this month.
 
re: polygon filling.. that should been fixed in rev 68.. from revisions.txt:
concave/convex polygons are now handled properly. just don't make
the last point of the polygon be the same as the first, otherwise
you'll confuse the tesselator. however! there is a bug (that showed
up during the release process.. ugh) that when smoothing is enabled,
sometimes thin lines will be visible within a concave polygon. this
will just have to be fixed in a future release. however, as long as  
stroke() is enabled on the polygon, the lines should not be visible.
or maybe you're running into the stroke/smooth bug?
« Last Edit: May 12th, 2004, 4:41am by fry »  
amoeba

WWW
Re: Status 11 May 2004
« Reply #5 on: May 12th, 2004, 9:30am »

Well, that's all good news. Open Source is very exciting, I just came back from the RAM 5 workshop on Open Source Media Architecture, which was a bit of an eye-opener.
 
I'll test the polygon filling on a new library I've written to import vector graphics from Illustrator files. For now it's done in a Java environment, but I'll hack it to work inside Processing so that I can release it as a library. If it works with filled polygons we could be looking at vector sprites... You can see a quick test here: BubblaTest.
 
As ever, thank you for your patience and diligence!
« Last Edit: May 12th, 2004, 9:48am by amoeba »  

marius watz // amoeba
http://processing.unlekker.net/
Ale_k

WWW
Re: Status 11 May 2004
« Reply #6 on: May 12th, 2004, 10:29pm »

Great news,
I suggest to name alpha 70:
Processing  - Haiku -
Pay off:
For poetic coder  or  code poetic  or minimal, emotional software.
 
 
Alessandro
 
Markavian

Markavian+iTX WWW
Re: Status 11 May 2004
« Reply #7 on: Oct 14th, 2004, 12:13am »

on May 12th, 2004, 4:24am, fry wrote:
however! there is a bug (that showed up during the release process.. ugh) that when smoothing is enabled,
sometimes thin lines will be visible within a concave polygon.

 
I've just ran into this bug porting some line draw code over from flash, not a very happy.. please make sure this is fixed for your next release! It is okay when I use a stroke, but for some reason the stroke (but not the fill) is being overlayed on top of any text I print afterwards!
 
fry

WWW
Re: Status 11 May 2004
« Reply #8 on: Oct 14th, 2004, 1:46am »

actually, that's a different bug (which is even more annoying), and was introduced by the same person who wrote the crappy polygon code. i've been running into it a bunch as well and will try to fix it soon.
 
Pages: 1 

« Previous topic | Next topic »