 |
Author |
Topic: Processing and C++ OpenGL Convertor (Read 1022 times) |
|
BillionNamesofGod
 
|
Processing and C++ OpenGL Convertor
« on: Aug 6th, 2004, 4:04am » |
|
Hi,
I just found processing, and seems like a good rapid prototyping tool for graphics.
I just thought, I know it's a beta program and maybe I'm probably being to silly about this, but:
Would it really be that difficult to program a translator/porter that converts a processing program into C++/OPENGL/GLUT.
This frankly would be amazing. It means we could use processing to create effects and general ease of use to prototype ideas.
Then, simply convert the processing program into a high-speed cross platform desktop application!!
Am I missing something? I really thing this should be an integral part of processing - the ability to create desktop apps form your work.
With all the opengl cross platform libraries outthere, it really should be difficult to mix a few, and be able to literally convert processing into a desktop application...
Is anybody up for the job?
I think if I was a student, I'll certainly like to do it as a project.
I think there is a great demand for a flexible development environment, that also creates high speed desktop applications!
It could all be opensource too with DEV C++, and GLUT and other openGL libraries like OPENML and CPW....
I just it would be really really cool!!!
|
|
|
|
|
TomC
|
Re: Processing and C++ OpenGL Convertor
« Reply #1 on: Aug 6th, 2004, 11:59am » |
|
I have been working on this, on and off. I reckon I have about 50% of the 2D API done.
There are some problems with it, mainly due to subtle differences between the Java and C++ way of declaring classes, arrays, inner classes, type-safety etc. A smart pre-processor could probably iron-out a lot of the problems though, and allow use of the color type.
That said, it's far more likely that porting the processing API to use hardware acceleration in Java would be quicker and easier.
For now, if you need standalone application functionality, there are lots of posts about it on this forum and in the tech-notes. It's not quite one-click publishing yet, but it's getting there 
|
|
|
|
|
REAS
|
Re: Processing and C++ OpenGL Convertor
« Reply #2 on: Aug 7th, 2004, 2:25am » |
|
There are two plans related to this discussion:
1. Ben is working on integrating JOGL:
https://jogl.dev.java.net/
JOGL is a set of Java bindings to OpenGL.
This will really speed things up. The first version of our JOGL integration will be quick and simple, but the addition of more specific code will create even greater speed increases.
2. The Processing _BETA_ release will support standalone applications.
Yes, we also feel these are integral to the project.
|
|
|
|
|
BillionNamesofGod
|
Re: Processing and C++ OpenGL Convertor
« Reply #3 on: Aug 8th, 2004, 9:18pm » |
|
Yes, of course JOGL makes complete sense!
The only thing is I've never used any Java Compilers..
I presume you can create actually machine code binary type executable from Java?
Rather than a program that runs the Java like an interpretor? (like all those BASIC game programming IDEs, that create an .exe but it's actually interpreted not compiled when it's executed)
The only advantage C++ has I think is speed and optimised compilers, java is just a more sensible clearer language all round for development.
Infact I don't think C++ is necessary, if it's possible to compile java into proper machine code .exe it's got to be just as fast as C++!
Is it possible to turn java into proper assembled machine code .exe, even though it was designed as a language to be interpreted on the fly? ( which is why it's slow for serious graphics stuff)
|
|
|
|
|
TomC
|
Re: Processing and C++ OpenGL Convertor
« Reply #4 on: Aug 8th, 2004, 9:34pm » |
|
Yes, it's possible to compile Java (tools such as Excelsior JET and GNU's GCJ do it). But VMs have other advantages (on the fly optimisation, compile once/run anywhere, etc). Java has it's own advantages too, like garbage collection, a massive standard library, and better software engineering tools (refactoring tools etc).
So yes, C++ for pure speed, but I don't think that's what Processing is all about. I'd trade 20% speed for clarity of expression and speed of development any time.
(That said, I'd love a full-screen hardware accelerated implementation of the Processing API, Java or not).
|
|
|
|
|
arielm
|
Re: Processing and C++ OpenGL Convertor
« Reply #5 on: Aug 8th, 2004, 10:47pm » |
|
on Aug 8th, 2004, 9:18pm, BillionNamesofGod wrote:| Is it possible to turn java into proper assembled machine code .exe, even though it was designed as a language to be interpreted on the fly ( which is why it's slow for serious graphics stuff) |
|
good news:
java has been an interpreted language for only a few years (its first years, a long long time ago...)
nowadays, any jvm you can think about (microsoft, sun, ibm...) is doing JIT (just in time compiling), so in other words: java byte code is "profiled" in real time and the critical parts are compiled to assembler on the fly before execution.
in term of performance, it's pretty close to standard c/c++ (as TomC mentioned) so that with today's boosted pc's, there's not a lot of reasons not to work with java (unless you like headaches and hate productivity )
(er, all this is true at least for windows where JIT compiling is doing miracles.... on mac, well, java is something still painfully slow!)
|
| « Last Edit: Aug 8th, 2004, 10:49pm by arielm » |
|
Ariel Malka | www.chronotext.org
|
|
|
gll
|
Re: Processing and C++ OpenGL Convertor
« Reply #6 on: Aug 12th, 2004, 1:09am » |
|
When I started with P5, I was learning OpenGL with C for a research project on Cellular Automatas. Those subtle differences as mention TomC, as how the loop is done is really different. I was looking for an programming environnement to test simple OpenGL objects. This is how felt in love with proce55ing concept.
But, at the beginning, it wasn't easy to switch from C to Java and I still can't imagine coding in both languages.
|
guillaume LaBelle
|
|
|
BillionNamesofGod
|
Re: Processing and C++ OpenGL Convertor
« Reply #7 on: Aug 17th, 2004, 2:01am » |
|
so you prefer C or Java
on Aug 12th, 2004, 1:09am, goo wrote:When I started with P5, I was learning OpenGL with C for a research project on Cellular Automatas. Those subtle differences as mention TomC, as how the loop is done is really different. I was looking for an programming environnement to test simple OpenGL objects. This is how felt in love with proce55ing concept.
But, at the beginning, it wasn't easy to switch from C to Java and I still can't imagine coding in both languages. |
|
|
|
|
|
|
gll
|
Re: Processing and C++ OpenGL Convertor
« Reply #8 on: Aug 31st, 2004, 8:47pm » |
|
I prefer Java. Simplier. When I started with P5, it was like magic with the loop() function. When I was coding with C++, I remember being lost with too much parameters at the same time. Maybe it's because I learned so much scince that I'm working with P5.
I'm curious about someone who did the inverse, starting with P5 and switching for C.
|
guillaume LaBelle
|
|
|
jingman
|
Re: Processing and C++ OpenGL Convertor
« Reply #9 on: Aug 31st, 2004, 10:49pm » |
|
I too think that this is important and cool.
I just started graduate classes on both openGL and VR implementation.
Should this project get off the ground, I can certainly be counted on as a tester - in fact, I can run the apps on our 12'x12'x12' 6 walled VR CAVE.
All this talk about future versions of p5, is there some thread about possible release dates? Beta, 1.0, what kind of timeline are we looking at?
|
| « Last Edit: Aug 31st, 2004, 10:49pm by jingman » |
|
|
|
|
|
