pouët.net

On the other hand if you can draw a line as a polygon in one line of code, is it that big a deal? :)

Lines aren't polygons and vice-versa. You know that. You go through all that shit to screen-align them and so on, though THERE IS EVEN HARDWARE SUPPORT FOR THIS KIND OF SHIT since the stone age!
Don't even get me started about points...

Sorry, I'm ranting... ;)

But unless you give the lines thickness you can't see them. And the best way to give them thickness is to turn them into thin rectangles, which is a small and trivial operation. But if you insist, then yes, a library that has polygon primitives should have line-with-width primitives too, for convenience. ;)

And teapots.

And ducks

and creepy monkeys

Please don't let wireframe duck die!

;)

on a side note, and since this thread stopped being on topic long ago... not knowing what a property getter does is horrible... i just optimized a (third-party) 30.000 record grid refresh update, from ~5 seconds to around ~0.2 seconds by just changing a "supposedly trivial" styling assignment (changing the font color vs. changing the whole row styling to a cached one, with just the font's fore color changed).

Yay!

back to libcinder, anyone used it? anyone compared it to something like openFrameworks?

would you use such a lib or would you code your own?

I use libcinder actively, and I used it for an iPhone game as a backend for my own framework. It's lovable, totally swell and all. However, it is very important to note that it's just a very thin layer and nothing too advanced. So, in pretty much every aspect of whatever you ar coding you're likely to require your own constructs; most likely building on top of what Cinder provides.

One thing I am dissappointed with is how it is packaged as a seemingly-C++ layer whereas it's missing the point of C++ being way more than just C-with-classes (I know this was the original name of it, but you get it). For example, it could have been optimized way more at certain places using some template meta-programming. Also in more than one instances I had to hack the source code of the library to add missing functionality to the very core classes (such as AppCocoaTouch not responding to activation / deactivation hence rendering multi-tasking on iOS pretty much impossible via Cinder).

So, is it good stone to sculpt into your very own David? Totally.
Is it a good all-in-one solution? Fuck no.

Offtopic:

Get a freaking clue. Or why would there exist a project called LLVM?

decipher: can you say anything on how it compares to oFrameWorks?

:§: i looked into it for a short while. i feel that when you get into details (the classes for shaders, textures, meshes, etc), it is horribly undocumented. basically, if you understand all the common graphics coding concepts and the entire graphics processing pipeline already (like, i guess, most coders here), it may help you not code so much if you never did a decently engine before (but only hacked stuff together).

for myself, this proved somewhat worthless, because i'm a more experienced programmer/ software designer than i am a graphics coding guru. once i understand a concept, rolling a class around e.g. a shader program or a triangle mesh doesn't feel so difficult. i'd hoped it would help me get stuff on screen *without* detailed low-level knowledge, and for that it's not much more useful than some library with just an image loader and a mesh loader.

for this reason, i dumped the whole framework approach altogether - they're all equally badly documented - and decided to get it over with and *really* learn graphics programming once and for all. or at least the parts i need.

button: Unfortunately I have never used OpenFrameWorks so I can't really say anything.

http://vimeo.com/17075378
Replacing points with spheres...