It's not that the RPI doesn't support OpenGL, it's that it's using OpenGL ES which drops some of the earlier GL 1.1 api, mainly intermediate mode. GEM can/will work fine on RPI if it's api is updated a bit to support ES (or through an emulation layer like glshim). This is a good idea in the long term anyway, since newer implementations of GL (3.3+) are also dropping support for the "old way" of doing things.
I've long thought that GEM could be ported to work on iOS, but I haven't had a need for it so haven't looked into it. In that case, there would need to be some function wrapping to support the old GL API, but this has already been done in libraries like OpenFrameworks, so they could be used as a template. Simple things like using a vertex array when setting vertex points in intermediate mode, etc ...
If the Udoo board has a regular GL 1.1, 2+ stack then it should work fine with GEM without any changes ... except that, unlike the RPI, it will require running X11 in order to use XGL. OpenFrameworks on the RPI, for instance, uses GLES without X11 and thereby doesn't waste resources on the windowing system. In my experience with embedded Linux system, it's best to ditch X if you truly do not need it. ON my old setup, X took almost 100 MB of ram on my 256 MB system. Running my custom SDL visual app directly to the framebuffer took only 1 couple of MBs by comparison.
Then again, embedded systems nowadays have more and more resources to burn so it may work without having to be frugal. (although efficiency is still important IMO).
On Sep 9, 2013, at 10:03 AM, pd-list-request@iem.at wrote:
From: Ali Momeni batchku@gmail.com Subject: Re: [PD] GEM on raspberry pi Date: September 9, 2013 10:02:52 AM EDT To: Dan Wilcox danomatika@gmail.com Cc: "pd-list@iem.at List" pd-list@iem.at
hello friends, i'm very keen to try GEM/openGL on a Udoo board (http://udoo.org) which DOES support OpenGL. if anyone is up for trying it i can provide you with a board to try on. should be a load of fun :)
ali
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Hello all, My bad, UDOO supports OpenGL ES 2.0 and OpenVG. So getting GEM working on it is closer to the RPi than i thought.
Are the porting efforts of GEM for RPi being documented somewhere? Is IOhannes m zmölnig still working on GEM?
ali
On Mon, Sep 9, 2013 at 10:53 AM, Dan Wilcox danomatika@gmail.com wrote:
It's not that the RPI doesn't support OpenGL, it's that it's using OpenGL ES which drops some of the earlier GL 1.1 api, mainly intermediate mode. GEM can/will work fine on RPI if it's api is updated a bit to support ES (or through an emulation layer like glshim). This is a good idea in the long term anyway, since newer implementations of GL (3.3+) are also dropping support for the "old way" of doing things.
I've long thought that GEM could be ported to work on iOS, but I haven't had a need for it so haven't looked into it. In that case, there would need to be some function wrapping to support the old GL API, but this has already been done in libraries like OpenFrameworks, so they could be used as a template. Simple things like using a vertex array when setting vertex points in intermediate mode, etc ...
If the Udoo board has a regular GL 1.1, 2+ stack then it should work fine with GEM without any changes ... except that, unlike the RPI, it will require running X11 in order to use XGL. OpenFrameworks on the RPI, for instance, uses GLES without X11 and thereby doesn't waste resources on the windowing system. In my experience with embedded Linux system, it's best to ditch X if you truly do not need it. ON my old setup, X took almost 100 MB of ram on my 256 MB system. Running my custom SDL visual app directly to the framebuffer took only 1 couple of MBs by comparison.
Then again, embedded systems nowadays have more and more resources to burn so it may work without having to be frugal. (although efficiency is still important IMO).
On Sep 9, 2013, at 10:03 AM, pd-list-request@iem.at wrote:
*From: *Ali Momeni batchku@gmail.com *Subject: **Re: [PD] GEM on raspberry pi* *Date: *September 9, 2013 10:02:52 AM EDT *To: *Dan Wilcox danomatika@gmail.com *Cc: *"pd-list@iem.at List" pd-list@iem.at
hello friends, i'm very keen to try GEM/openGL on a Udoo board (http://udoo.org) which DOES support OpenGL. if anyone is up for trying it i can provide you with a board to try on. should be a load of fun :)
ali
Dan Wilcox @danomatika danomatika.com robotcowboy.com
It is still a really interesting platform…
Have you been using it successfully with Pd & sensors? Is there a Pd binary? How do usb sound cards work with Udoo? On of the nice things about the pi is that you can access pins form within pd with the pi external. is there something like this in Udoo?
best,
J
On Sep 9, 2013, at 11:00 AM, Ali Momeni batchku@gmail.com wrote:
Hello all, My bad, UDOO supports OpenGL ES 2.0 and OpenVG. So getting GEM working on it is closer to the RPi than i thought.
Are the porting efforts of GEM for RPi being documented somewhere? Is IOhannes m zmölnig still working on GEM?
ali
On Mon, Sep 9, 2013 at 10:53 AM, Dan Wilcox danomatika@gmail.com wrote: It's not that the RPI doesn't support OpenGL, it's that it's using OpenGL ES which drops some of the earlier GL 1.1 api, mainly intermediate mode. GEM can/will work fine on RPI if it's api is updated a bit to support ES (or through an emulation layer like glshim). This is a good idea in the long term anyway, since newer implementations of GL (3.3+) are also dropping support for the "old way" of doing things.
I've long thought that GEM could be ported to work on iOS, but I haven't had a need for it so haven't looked into it. In that case, there would need to be some function wrapping to support the old GL API, but this has already been done in libraries like OpenFrameworks, so they could be used as a template. Simple things like using a vertex array when setting vertex points in intermediate mode, etc ...
If the Udoo board has a regular GL 1.1, 2+ stack then it should work fine with GEM without any changes ... except that, unlike the RPI, it will require running X11 in order to use XGL. OpenFrameworks on the RPI, for instance, uses GLES without X11 and thereby doesn't waste resources on the windowing system. In my experience with embedded Linux system, it's best to ditch X if you truly do not need it. ON my old setup, X took almost 100 MB of ram on my 256 MB system. Running my custom SDL visual app directly to the framebuffer took only 1 couple of MBs by comparison.
Then again, embedded systems nowadays have more and more resources to burn so it may work without having to be frugal. (although efficiency is still important IMO).
On Sep 9, 2013, at 10:03 AM, pd-list-request@iem.at wrote:
From: Ali Momeni batchku@gmail.com Subject: Re: [PD] GEM on raspberry pi Date: September 9, 2013 10:02:52 AM EDT To: Dan Wilcox danomatika@gmail.com Cc: "pd-list@iem.at List" pd-list@iem.at
hello friends, i'm very keen to try GEM/openGL on a Udoo board (http://udoo.org) which DOES support OpenGL. if anyone is up for trying it i can provide you with a board to try on. should be a load of fun :)
ali
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-09-09 17:00, Ali Momeni wrote:
Is IOhannes m zmölnig still working on GEM?
some hours ago, an email was posted in this thread that said:
On 2013-09-09 13:37, IOhannes m zmoelnig wrote:
luckily the git version of Gem has alternative windowing code (still highly experimental), e.g. using SDL or GLFW, which might work.
from this i'd conclude:
- there exists a development version of Gem (using "git")
- there are "highly experimental" features in this branch
from this i'd conclude that Gem is still alive. and since the author of that email also used to be the maintainer of Gem, he's probably *still* involved.
so yes, he is. (he also has a day job)
fgmasdr IOhannes
Hello,
On Mon, Sep 9, 2013 at 11:07 AM, jo57 jaime.oliver2@gmail.com wrote:
It is still a really interesting platform…
indeed!
Have you been using it successfully with Pd & sensors? Is there a Pd binary?
i compiled the latest from miller's site: http://msp.ucsd.edu/software.html
so i have 0.45 working, audio is fine; the api/specs/docs on the GPIO and analog sensor pins on the UDOO are MINIMAL. i'm working on getting them going.
How do usb sound cards work with Udoo?
been using the built-in audio; it has 1/8" in/out in addition to the HDMI
On of the nice things about the pi is that you can access pins form within pd with the pi external. is there something like this in Udoo?
absolutely. the GPIO setup on the UDOO is the same as the PI (i.e. the is a special folder with a subfolder for each pin and the params for each pin is a file. the GPIO pd extern that miller has ( http://msp.ucsd.edu/syllabi/206.13w/index.htm) should work just fine; i'm only waiting for the pin-numbering diagram from UDOO folks...
a
best,
J
On Sep 9, 2013, at 11:00 AM, Ali Momeni batchku@gmail.com wrote:
Hello all, My bad, UDOO supports OpenGL ES 2.0 and OpenVG. So getting GEM working on it is closer to the RPi than i thought.
Are the porting efforts of GEM for RPi being documented somewhere? Is IOhannes m zmölnig still working on GEM?
ali
On Mon, Sep 9, 2013 at 10:53 AM, Dan Wilcox danomatika@gmail.com wrote:
It's not that the RPI doesn't support OpenGL, it's that it's using OpenGL ES which drops some of the earlier GL 1.1 api, mainly intermediate mode. GEM can/will work fine on RPI if it's api is updated a bit to support ES (or through an emulation layer like glshim). This is a good idea in the long term anyway, since newer implementations of GL (3.3+) are also dropping support for the "old way" of doing things.
I've long thought that GEM could be ported to work on iOS, but I haven't had a need for it so haven't looked into it. In that case, there would need to be some function wrapping to support the old GL API, but this has already been done in libraries like OpenFrameworks, so they could be used as a template. Simple things like using a vertex array when setting vertex points in intermediate mode, etc ...
If the Udoo board has a regular GL 1.1, 2+ stack then it should work fine with GEM without any changes ... except that, unlike the RPI, it will require running X11 in order to use XGL. OpenFrameworks on the RPI, for instance, uses GLES without X11 and thereby doesn't waste resources on the windowing system. In my experience with embedded Linux system, it's best to ditch X if you truly do not need it. ON my old setup, X took almost 100 MB of ram on my 256 MB system. Running my custom SDL visual app directly to the framebuffer took only 1 couple of MBs by comparison.
Then again, embedded systems nowadays have more and more resources to burn so it may work without having to be frugal. (although efficiency is still important IMO).
On Sep 9, 2013, at 10:03 AM, pd-list-request@iem.at wrote:
*From: *Ali Momeni batchku@gmail.com *Subject: **Re: [PD] GEM on raspberry pi* *Date: *September 9, 2013 10:02:52 AM EDT *To: *Dan Wilcox danomatika@gmail.com *Cc: *"pd-list@iem.at List" pd-list@iem.at
hello friends, i'm very keen to try GEM/openGL on a Udoo board (http://udoo.org) which DOES support OpenGL. if anyone is up for trying it i can provide you with a board to try on. should be a load of fun :)
ali
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Right now with glshim I get stuck on glPixelMap functions, which don't seem exactly trivial: http://www.opengl.org/sdk/docs/man2/xhtml/glPixelMap.xml
The dev told me I could try making some empty 'scaffold' functions if these are not used by anything in particular. I have no clue which features glshim is still missing in order to get GEM running.
@ IOhannes: work less hours man :P
On Mon, Sep 9, 2013 at 5:12 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-09-09 17:00, Ali Momeni wrote:
Is IOhannes m zmölnig still working on GEM?
some hours ago, an email was posted in this thread that said:
On 2013-09-09 13:37, IOhannes m zmoelnig wrote:
luckily the git version of Gem has alternative windowing code (still highly experimental), e.g. using SDL or GLFW, which might work.
from this i'd conclude:
- there exists a development version of Gem (using "git")
- there are "highly experimental" features in this branch
from this i'd conclude that Gem is still alive. and since the author of that email also used to be the maintainer of Gem, he's probably *still* involved.
so yes, he is. (he also has a day job)
fgmasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlIt5W4ACgkQkX2Xpv6ydvSB3ACfVZ29W76rY5GPuMRRWStPFC0f mGsAn2HdHapQ6ZnIeoiTIZreDH7kzftG =depF -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Ali Momeni -
Dan Wilcox -
dreamer -
IOhannes m zmoelnig -
jo57