Hi, zmoelnig@iem.at hat gesagt: // zmoelnig@iem.at wrote:
Quoting tigital tigital@mac.com:
...good idea: when I did the OS X port, I thought about doing it via
SDL, but went with native support in the end...I don't know that it would help existing implementations, but I think gridflow has some sdl support, so maybe it'd help to get gridflow and gem to work together (if desired?)...
...at any rate, I love sdl!
i was just thinking about sthg like this today when talking about aalib. i would really like Gem to run on console only machines too (at least under linux/un*x); this would not break my ideas of platform independence, since only the output would be platform dependent (which it is anyhow)
ah yes, SDL is supported by aalib.
This brings up the question, what Gem should be? It started as a kind of wrapper around OpenGL, then video came in, but still processed in OpenGL (I suspect. I never used the video stuff).
Now SDL also is a wrapper around OpenGL and around a lot of other things, including sound ;) I see, that SDL might be easier to program.
But one of my dreams would be, to be able to design patcher objects in Gem (or another GUI-interface). That means, having a fast OpenGL area inside Pd patches, not (but possibly) in an extra window. I wonder, if SDL is as 'embedable' as OpenGl (which is for example like in gtkglarea, wxwindos, ...)
But this might lead to a Pd toolkit discussion again...
Frank Barknecht _ ______footils.org__