I understand your concerns, and agree that maintaining support for older computers is an important factor to keep in mind in a project like Processing. The newest and fanciest hardware is not required for many things you can do with Processing, teaching creative coding being one of them. However, there are other factors to take into account, such as keeping the core of Processing relatively simple and the number of developers who can effectively maintain all the features included in the core. Given the amont of work that would take to maintain the old P2D and P3D renderers, a decision was taken to replace them with the new OpenGL2-based ones. 

This being said, the JAVA2D renderer in Processing 2.0 is still present and should work in PC's without any sort of OpenGL acceleration. In order to do 3D drawing in older hardware, you can always rely on the 1.x releases. Furthermore, it is also possible to implement additional renderers in Processing 2.0 that offer 3D rendering based on OpenGL 1.x or even entirely on the CPU, through the mechanism of external libraries. The open source nature of Processing should make this easier to anyone who has the interest to do so.

Andres

But my point is: Processing is meant to work "out of the box" and especially in class rooms but with OpenGL 2 as requirement I think we face a lack of retro-compatibility with older computers. And class rooms, especially in not so rich environments, have often old computers, Intel integrated chipsets and also GNU/Linux.

So when I speak about being on the edge I mean "we want to use Processing 2.0 as everybody".

Jeff, don't take me wrong: I'm not saying that Processing should make miracles giving super acceleration for everybody but without P3D we don't have the third dimension at all! You should see the faces of my young students when, just using PeasyCam for example, we could have a 3D camera moving around while not changing a line of their works... It's like WOW! ;-)

Clarified that, I think Andres is right about the possibility to implement 3D renderes without GPU and probably we can find some cool open source solution!

1) If you need to work on low profile computers then stay as close as you can to 1.5.1 while maintaining your code fully compatible with 2.0

2) Somebody may develop a renderer as a library that could implement new 2.0 features and APIs without OPENGL2. This would be done, as suggested by Andres, starting filling the gap between old and new PGraphics3D implementation

Thinking about this old vs new hardware small war I reminded the "old times" when videogames developers were used to implement so many different renderers to be compatible with as many hardware configurations as possible! Probably those workers faced a nightmare. But customers could enjoy games without being rich people!

I propose the creation of a NOSTALGIA renderer! 

What do you think?

However I completely understand Processing making OpenGL2 a requirement.  It is a smart and sane decision, and it will allow the devs to finally fix many of the problems that were remaining due to the use of OpenGL 1.x

With respect to those using GNU/Linux on platforms with GMA3150 Intel integrated chipset present in many netbooks such as mine (Samsung N150), you might be interested in installing driconfig and setting "Enable limited ARB_fragment_shader support on 915/945" to true.  I haven't tried it myself with the new processing alphas, but when I try it I will come back here with the results.

Creating the NOSTALGIA renderer sounds awesome, but seems like a lot of work and maintenance.

Hi all!

I want to address the issue of OpenGL 2.0 being "old" technology from 2004.

If you pay any attention to the hardware market, the netbooks coming out these days still don't support OpenGL 2.0 even on Windows.  

Let me reiterate: many people buy new computers today without OpenGL 2.0 support.

In light of this, simultaneously deprecating P3D and forcing OpenGL 2.0 is horrendous and goes against what this language is supposed to be. The advice to use the old version is not a solution, nor it is a workaround to the problem that the language is broken in an update to the new version.

So, now I have the following problem: Processing 2.0 doesn't run on any hardware I own, and the only "solution" is to not use it at all.

This would not be a huge deal if I didn't want to deploy sketches to be seen by everyone. 

In addition, 1.5.1 doesn't have the features 2.0 has (in particular, exporting as a JS).

Processing 2.0 is still in an alpha stage... you shouldn't be complaining that it's broken for you.

It's not broken for just me. It's broken for everyone who has older hardware, such as the OP.

I am not complaining about OpenGL2 being supported in 2.0, I am complaining about Open GL 1.5 not working, and P3D deprecated.

Of course I am thankful that I have Processing at all. And as thankful as I am, I want to use the new version when it comes out, but I won't be able to. And I absolutely hate when people create something awesome, and remove vital features in the update. 

I love Processing, I want to continue loving it and using it, and I want other people to be using it. However, I can't recommend it to anyone now that the new version doesn't run even on my machine. Updates shouldn't break important functionality like that.

So I am pointing out that lack of P3D and OpenGL 1.5 support makes Processing useless for its target audience. I think this is something that the developers should know. Take it as a bug report.

Have no clue how to test it myself since I have an OPENGL graphic card, but please go ahead and try it out here: http://ixagon.se/oldp3d/

Edit: Oh, and should have mentioned. The renderer is called OldP3D.OldP3D. I'll update with an example.

You should add the NOSTALGIA constant as well, as Massimo suggested earlier, so you can initialize it with size(width, height, OldP3D.NOSTALGIA)   :-)

Hey, it's me who should thank you! I'm struggling a bit to get the PShape to work. When I run any of the PShape examples with the NOSTALGIA renderer I get:

If I pack the old PShape.java with the library I get the ambiguous error since it can't choose which PShape.java to run.

It seems like PShape is rewritten and the loadShape method is inside PApplet.java, which I don't want to include in the library.

Any suggestions? 

This actually brings up another issue: the convention is to use class names starting with "P" only for those in the core, so it is probably a good idea to rename PLine, PTriangle, etc.

Been experimenting on adding the old PShape and PShapeSVG and renaming them, but then I have to rewrite the hole PShapeSVG class since it uses XMLElement, I don't fancy the idea of that. :-)

Also, the loadShape method returns a PShape from core, if I rename PShape I have to rewrite big parts of the core and include them in the library.

I think that adding the following method to the renderer:

1.   public PShape loadShape(String filename) {
2.     String extension = PApplet.getExtension(filename);
3. 
   
4.     PShapeSVG svg = null;
5. 
   
6.     if (extension.equals("svg")) {
7.       svg = new PShapeSVG(parent, filename);
8. 
   
9.     } else if (extension.equals("svgz")) {
10.       try {
11.         InputStream input = new GZIPInputStream(parent.createInput(filename));
12.         XML xml = new XML(PApplet.createReader(input));
13.         svg = new PShapeSVG(xml);
14.       } catch (IOException e) {
15.         e.printStackTrace();
16.       }
17.     } else {
18.       PGraphics.showWarning("Unsupported format");
19.     }
20. 
    
21.     return svg;
22.   }

should be enough.

The PShape examples are running fine, but I get these errors.

Thank you, andres and bustup! 3D now works in Processing 2.0a on my netbook. Drawing 3D shapes with beginShape(QUAD_STRIP)..endShape() works as before. 

Thanks again for this work! I hope they include old P3D in 2.0 as a standard library like this when it comes out.