libcinder
category: code [glöplog]
just mentioned by broderick in the oneliner: libcinder, a democoding library by and for non-sceners.
did anyone try it out? at a first glance, it looks pretty decent.
did anyone try it out? at a first glance, it looks pretty decent.
Can you compare that to processing or that other C++ all purpose multimedia library in a nutshell?
*openFrameworks
from initial fast reading for their tutorials it looks great. i might test it later on :o
me 2!
wow, this is indeed really cool. The API seems really easy to use, well integrated with openGL, font,audio handling, builtin supports for keyboard,mouse, 2D graphics with cairo (although I don't know if the opengl backend for cairo is working well), handling demo resources easily both for mac & windows. Generated exe's are quite small for this kind of versatile framework (around 500Ko for a simple application), with no external dll dependencies (apart from the openGL stuf)...
Definitely something to look at for building a demo with it....
Definitely something to look at for building a demo with it....
hornet: this has nothing to do with real time coding.
that's an other world.
that's an other world.
xrl: its faster then p5 or of. most of the people who worked with p5 and of are moving to cinder. still abit beta though.
p5 is build on java, cinder on c++, ofcource cinder is a thousand times faster.
whynot2000: assuming the GPU is the bottleneck, I don't see why.
and assuming it isn't - that JVM JIT is pretty decent these days.
i don't know shit about processing, but isn't that an interpreted language, where the interpreter happens to be written in java? i'd say that the fact that it's interpreted might make a much larger difference than whether the underlying framework is java or cpp.
otherwise, the only reason i can come up with why java (or any highlevel VM language) for realtime graphics may still be significantly slower than c/c++ is that probably you can't copy a java.util.Vector<Vertex> directly into VRAM, whereas with a std::vector<Vertex> you often can. if your vertex data is a lot and changing every frame (these artsy guys don't tend to do 3ds flybys), the conversion step may be a fair bottleneck. so closer-to-the-hardwareness, rather than pure computing power may be the main reason they moved to c++.
but then again, in all honesty I've no idea about this stuff. just speculating.
and assuming it isn't - that JVM JIT is pretty decent these days.
i don't know shit about processing, but isn't that an interpreted language, where the interpreter happens to be written in java? i'd say that the fact that it's interpreted might make a much larger difference than whether the underlying framework is java or cpp.
otherwise, the only reason i can come up with why java (or any highlevel VM language) for realtime graphics may still be significantly slower than c/c++ is that probably you can't copy a java.util.Vector<Vertex> directly into VRAM, whereas with a std::vector<Vertex> you often can. if your vertex data is a lot and changing every frame (these artsy guys don't tend to do 3ds flybys), the conversion step may be a fair bottleneck. so closer-to-the-hardwareness, rather than pure computing power may be the main reason they moved to c++.
but then again, in all honesty I've no idea about this stuff. just speculating.
oh, no i'm wrong, processing isn't interpreted. my bad.
processing isn't a language, processing is just a library for java.
it IS interpreted. (the processing environment some macro-ing to emulate an extra native type "color")
and it is slow, OGL with java just is.
i started writing a bullethell game in processing (in eclipse) but i had to port it to a faster language; too much sprites!
using sfml now, put that piece of crap can't seen to draw fonts without crashing, it's too much of a work in progress, maybe in a few months or such.
it IS interpreted. (the processing environment some macro-ing to emulate an extra native type "color")
and it is slow, OGL with java just is.
i started writing a bullethell game in processing (in eclipse) but i had to port it to a faster language; too much sprites!
using sfml now, put that piece of crap can't seen to draw fonts without crashing, it's too much of a work in progress, maybe in a few months or such.
Quote:
processing isn't a language, processing is just a library for java.
nonsense. it is a language that is converted into java source code, which in turn is compiled into jvm bytecode. sure thing, the conversion is nigh-on trivial, but it's not the same.
The convertion to java source code is more or less just adding some kind of header (a bunch of imports and a class definition) and a footer ( "}" ), so it actually is plain java.
erm, no. srsly, check it out :p
the whole of p5 is just java, and all you do is overwrite an existing class* in the non-functional 'default' program that has lots of methods and other classes in it.
all you do is overloading the setup() and the draw() method in that program.
if you program in the p5 IDE instead of an ordinary java IDE (like eclipse) there is an emulated type 'color' (actually just an int) and including recources and other classes and stuff has been made simpler.
but eclipse works way better when you use lots of classes and such.
*it is packed in java bytecode, but it isn't compiled. so it's just the same as if you'd include the .java files instead of the compressed .class files, which you can actually do btw. but there's no point in doing that unless you want to mess with the p5 source.
if you look at the source of core.class you can actually find the abstract classes setup and draw.
AAAANYWAYS, anybody checked out cinder already? i'm on it, preeetty sweet. hating that it's not C# though.
the whole of p5 is just java, and all you do is overwrite an existing class* in the non-functional 'default' program that has lots of methods and other classes in it.
all you do is overloading the setup() and the draw() method in that program.
if you program in the p5 IDE instead of an ordinary java IDE (like eclipse) there is an emulated type 'color' (actually just an int) and including recources and other classes and stuff has been made simpler.
but eclipse works way better when you use lots of classes and such.
*it is packed in java bytecode, but it isn't compiled. so it's just the same as if you'd include the .java files instead of the compressed .class files, which you can actually do btw. but there's no point in doing that unless you want to mess with the p5 source.
if you look at the source of core.class you can actually find the abstract classes setup and draw.
AAAANYWAYS, anybody checked out cinder already? i'm on it, preeetty sweet. hating that it's not C# though.
And here I am having fun hunting for days to find that bad pointer...
Quote:
whynot2000: assuming the GPU is the bottleneck, I don't see why.
and assuming it isn't - that JVM JIT is pretty decent these days.
Java isn't just slow because the bytecode needs translation. It also suffers from:
- not letting you allocate objects on the stack - anything but primitive types must use heap allocations
- not having unions: no float x,y,z = int32 dataThatYouCanAccessWithoutTheFPU[3] or similar tricks
- enforcing runtime index checks on arrays
- not supporting pointers, instead forcing you to use iterators or array indices, which makes tight loops produce much less tight code
- forcing the programmer to adopt lazy resource management patterns: no deterministic destruction, no lifetimes tied to scopes, no RAII - which is especially important when you want tight control over GPU buffers because video memory is a scarce resource.
Even if Java compiled to native machine code, it still wouldn't easily replace C++ for high performance applications, especially when you're relying on external resources like a GPU that the JVM doesn't have complete control over (unlike say Java's own heap which it manages very efficiently through GC.)
Quote:
this has nothing to do with real time coding.
true, but it's not that far off from rapid prototyping - which is kinda how I view libcinder/processing/openframeworks etc.
As much as I dislike Java, some things said here are incorrect.
The good JIT (-server) can put objects on the stack through escape analysis.
http://stackoverflow.com/questions/771430/escape-analysis-in-java (see 2nd answer)
Hotspot -server does static analysis to eliminate those.
An alternative is to release the resource before the object destruction.
As an example, C++'s fstream has a close() function.
Moreover, a C++ detructor can't throw, so it might actually be safer.
Quote:
- not letting you allocate objects on the stack - anything but primitive types must use heap allocations
The good JIT (-server) can put objects on the stack through escape analysis.
http://stackoverflow.com/questions/771430/escape-analysis-in-java (see 2nd answer)
Quote:
- enforcing runtime index checks on arrays
Hotspot -server does static analysis to eliminate those.
Quote:
- forcing the programmer to adopt lazy resource management patterns: no deterministic destruction, no lifetimes tied to scopes, no RAII - which is especially important when you want tight control over GPU buffers because video memory is a scarce resource.
An alternative is to release the resource before the object destruction.
As an example, C++'s fstream has a close() function.
Moreover, a C++ detructor can't throw, so it might actually be safer.
oh great, java vs c++ all over again. we never had that discussion before.
Back to the topic, Cinder is a project partially by Robert Hodgin (ex-Barbarian) a.k.a. Flight404. So, it explains its simple and purpose-built nature and it being a somehow cooler Processing.
I'm very interested in it actually, will take a look.
I'm very interested in it actually, will take a look.
Decipher: Not quite. Flight404 is using it for some projects, but he is not listed as a developer nor describes himself as one. While he did work at The Barbarian Group at some point, I haven't come over any evidence that he helped write libcinder.
Oh, I stand corrected. Thanks, kusma. :)
Fuck the topic. ;)
ponce: I accept that the JVMs are always improving. And apparently quite a bit since I last checked. I'd still be skeptical of any form of static or dynamic analysis applying well to real code, though, as opposed to simple benchmarks.
I mean, you want to allocate a new object; so apparently, this is either O(1) or O(0). In the simple case, it doesn't matter. You're happy to get the stack allocation, but O(1) isn't too bad. But what about allocating an n x n matrix? That's either an O(0) or O(n^2) operation. Which is a big difference. And you don't know, because everything is left to obscure internals of the VM. That's not the sort of uncertainty you want in a high-performance app like, say, a demo. And exactly how deep is the search for escaping pointers, anyway? How deep will it be in the next version of the VM, or on some other brand of VM?
Getting rid of all these questions may be well worth having to make a few stack vs. heap decisions along the way.
Same thing for static analysis. A static loop may be easily bound-checked at compile time, but there are other things you might subject an array to than that. The compiler might recognise that array[ index % size_of_array ] is safe, but what about array[ index & ( size_of_array - 1 ) ]?
That's not really an alternative. It's true that RAII isn't what makes resource management possible, but it does make it cleaner, less error-prone and (mostly) more efficient.
As an alternative to RAII, you can call a bunch of close() methods at the end of every scope as you suggest. And yes, if you wrap everything in try/finally blocks, and you're extremely careful, you can probably get away with it. But that's barely scraping the surface of resource management. It's very hard to beat a good C++ smart pointer template when things get less trivial. Because C++ deliberately caters to RAII programming. Java (deliberately?) more or less ignores the issue of external resource management.
Anyway, the bigger point is just that there's more to Java being unsuited for certain tasks than the bytecode. It's a different language, so it's useful in different ways, is what I'm saying. Just consider passing an array of 3D vectors to DirectX; DX wants arrays of values, not arrays of pointers, so this is an expensive operation in Java. In C++, it's virtually free.
ponce: I accept that the JVMs are always improving. And apparently quite a bit since I last checked. I'd still be skeptical of any form of static or dynamic analysis applying well to real code, though, as opposed to simple benchmarks.
I mean, you want to allocate a new object; so apparently, this is either O(1) or O(0). In the simple case, it doesn't matter. You're happy to get the stack allocation, but O(1) isn't too bad. But what about allocating an n x n matrix? That's either an O(0) or O(n^2) operation. Which is a big difference. And you don't know, because everything is left to obscure internals of the VM. That's not the sort of uncertainty you want in a high-performance app like, say, a demo. And exactly how deep is the search for escaping pointers, anyway? How deep will it be in the next version of the VM, or on some other brand of VM?
Getting rid of all these questions may be well worth having to make a few stack vs. heap decisions along the way.
Same thing for static analysis. A static loop may be easily bound-checked at compile time, but there are other things you might subject an array to than that. The compiler might recognise that array[ index % size_of_array ] is safe, but what about array[ index & ( size_of_array - 1 ) ]?
Quote:
An alternative is to release the resource before the object destruction.
As an example, C++'s fstream has a close() function.
Moreover, a C++ detructor can't throw, so it might actually be safer.
That's not really an alternative. It's true that RAII isn't what makes resource management possible, but it does make it cleaner, less error-prone and (mostly) more efficient.
As an alternative to RAII, you can call a bunch of close() methods at the end of every scope as you suggest. And yes, if you wrap everything in try/finally blocks, and you're extremely careful, you can probably get away with it. But that's barely scraping the surface of resource management. It's very hard to beat a good C++ smart pointer template when things get less trivial. Because C++ deliberately caters to RAII programming. Java (deliberately?) more or less ignores the issue of external resource management.
Anyway, the bigger point is just that there's more to Java being unsuited for certain tasks than the bytecode. It's a different language, so it's useful in different ways, is what I'm saying. Just consider passing an array of 3D vectors to DirectX; DX wants arrays of values, not arrays of pointers, so this is an expensive operation in Java. In C++, it's virtually free.