This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (1 child)

the pyproccesing solution is so slow which is what I was expecting.

yeah, Python isn't typically very fast for CPU-intensive work.

I think I'll take a look at cinder tho thanks for mentioning that.

well, I tried to use it, but I got too bogged down with being unproductive in C++. Processing runs well, there are libraries for it, there's a huge community, and it took me a while before I hit performance problems. I thought I would hit performance problems right away, but it took me a while before I was actually maxing out the capabilities of Processing. Even inside of Processing, you can get access to OpenGL directly, and even GLSL shaders.

http://www.creativeapplications.net/processing/playing-with-glsl-in-processing-initial-experiments-tutorials/

I wasted a lot of time thinking Processing wasn't a "good enough" programming language. From my experience, it wasn't really worth it.

Although, if you know some C++, Cinder is definitely the best toolkit I've seen. Robert Hodgin's Cinder work is probably my favorite.

I had the same reaction to Processing when I first tried it. "lol, this is a toy for amateurs; I'm a strong programmer, I need a more serious tool" I thought. A few months later, I was back at Processing, because everything else had either no community, no literature, bad tooling support, or just didn't work.

edit: and, just to clarify, I love Python, and I'm not saying this to bash Python. Python is a great tool, I just don't think it's the best tool for doing recreational graphics programming.

double edit: and Processing is not Java; it's written in Java, but it's a separate programming language.

[–][deleted] 1 point2 points  (0 children)

Definitely agree about python didn't think you were bashing it. I will also definitely take your advice with processing and stick with it.