I would be totally *possible* to update GEM to support OpenGL ES. It mainly involves replacing the immediate mode functions and a few wrappers for defines which ES doesn’t use. We do this in OpenFrameworks.
The main problem, like everything, is who has the time to do it?
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Mar 15, 2015, at 4:00 AM, pd-list-request@lists.iem.at wrote:
From: Cyrille Henry <ch@chnry.net mailto:ch@chnry.net> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at Date: March 15, 2015 at 2:47:02 AM PDT Subject: Re: [PD] Gem on Raspberry pi 2
Le 15/03/2015 04:11, Simon Wise a écrit :
Apparently there is some support beyond Es, but not enough to run gem and as not at all documented.
i was to much optimistic and did not double check the informations i found announcing openGL support. thanks for the clarification. cheers c
we discuss that a few in the past and afair we conclude that mobile devices will support OpenGL sooner than an OpenGL ES Gem will arrived but maybe this not true anymore, maybe mobile devices will never support OpenGL and will stuck in ES, which is enough for them so in that way, i could be nice to upgrade Gem to run OpenGL ES.
Maybe we can grab some code from OFX to do that. But anyway, my 2 cent seems to not move forward that discussion so much...
-- do it yourself http://antoine.villeret.free.fr
2015-03-17 14:55 GMT+01:00 Dan Wilcox danomatika@gmail.com:
I would be totally *possible* to update GEM to support OpenGL ES. It mainly involves replacing the immediate mode functions and a few wrappers for defines which ES doesn’t use. We do this in OpenFrameworks.
The main problem, like everything, is who has the time to do it?
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Mar 15, 2015, at 4:00 AM, pd-list-request@lists.iem.at wrote:
*From: *Cyrille Henry ch@chnry.net *To: *pd-list@lists.iem.at *Date: *March 15, 2015 at 2:47:02 AM PDT *Subject: **Re: [PD] Gem on Raspberry pi 2*
Le 15/03/2015 04:11, Simon Wise a écrit :
Apparently there is some support beyond Es, but not enough to run gem and as not at all documented.
i was to much optimistic and did not double check the informations i found announcing openGL support. thanks for the clarification. cheers c
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
it's not only openGL-ES, openGL 3.0 also depreciate the glBegin / glEnd loop.
I've got the impression that it's not a big deal for software compatible with opengl 3 or 4 to be compatible with openGL ES and being compatible with recent openGL version is important since lot's of new shader are available.
in the future, most primitives will have to be rewrited and then, they also be compatible with openGLES. or maybe they could just be ignored...
anyhow, would it be easy to build a GemES where all primitive using glbegin / glEnd would be removed? as long as gemvertexbuffer and shader are available, lot's of things can be done...
what i currently dreaming of is : if openGL available version is > 3 : adding a message to gemwin to specify the openGL version used to create the context. (this is possible since openGL remove functionalities in newer version) if a context is created with a openGL > 3, or openGL-ES, then drop support for all primitive that are not compatible. and add new object for new functionalities...
then, object like cube / circle etc could be ported as abstractions
so, my point is : if the only problem for porting Gem to openGL-ES is the primitives, then we should port Gem without primitives...
cheers c
Le 17/03/2015 15:03, Antoine Villeret a écrit :
we discuss that a few in the past and afair we conclude that mobile devices will support OpenGL sooner than an OpenGL ES Gem will arrived but maybe this not true anymore, maybe mobile devices will never support OpenGL and will stuck in ES, which is enough for them so in that way, i could be nice to upgrade Gem to run OpenGL ES.
Maybe we can grab some code from OFX to do that. But anyway, my 2 cent seems to not move forward that discussion so much...
-- do it yourself http://antoine.villeret.free.fr
2015-03-17 14:55 GMT+01:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
I would be totally *possible* to update GEM to support OpenGL ES. It mainly involves replacing the immediate mode functions and a few wrappers for defines which ES doesn’t use. We do this in OpenFrameworks. The main problem, like everything, is who has the time to do it? -------- Dan Wilcox @danomatika danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Mar 15, 2015, at 4:00 AM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: *From:*Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>> *To:*pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> *Date:*March 15, 2015 at 2:47:02 AM PDT *Subject:**Re: [PD] Gem on Raspberry pi 2* Le 15/03/2015 04:11, Simon Wise a écrit :Apparently there is some support beyond Es, but not enough to run gem and as not at all documented.i was to much optimistic and did not double check the informations i found announcing openGL support. thanks for the clarification. cheers c_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The primitives and other immediate mode stuff can be implemented with VBAs, etc see https://github.com/openframeworks/openFrameworks/blob/master/libs/openFramew... https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/gl/ofGLRenderer.cpp#L1346 which will work in older versions of GL as well as the current version.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Mar 17, 2015, at 7:50 AM, Cyrille Henry ch@chnry.net wrote:
it's not only openGL-ES, openGL 3.0 also depreciate the glBegin / glEnd loop.
I've got the impression that it's not a big deal for software compatible with opengl 3 or 4 to be compatible with openGL ES and being compatible with recent openGL version is important since lot's of new shader are available.
in the future, most primitives will have to be rewrited and then, they also be compatible with openGLES. or maybe they could just be ignored...
anyhow, would it be easy to build a GemES where all primitive using glbegin / glEnd would be removed? as long as gemvertexbuffer and shader are available, lot's of things can be done...
what i currently dreaming of is : if openGL available version is > 3 : adding a message to gemwin to specify the openGL version used to create the context. (this is possible since openGL remove functionalities in newer version) if a context is created with a openGL > 3, or openGL-ES, then drop support for all primitive that are not compatible. and add new object for new functionalities...
then, object like cube / circle etc could be ported as abstractions
so, my point is : if the only problem for porting Gem to openGL-ES is the primitives, then we should port Gem without primitives...
cheers c
Le 17/03/2015 15:03, Antoine Villeret a écrit :
we discuss that a few in the past and afair we conclude that mobile devices will support OpenGL sooner than an OpenGL ES Gem will arrived but maybe this not true anymore, maybe mobile devices will never support OpenGL and will stuck in ES, which is enough for them so in that way, i could be nice to upgrade Gem to run OpenGL ES.
Maybe we can grab some code from OFX to do that. But anyway, my 2 cent seems to not move forward that discussion so much...
-- do it yourself http://antoine.villeret.free.fr
2015-03-17 14:55 GMT+01:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
I would be totally *possible* to update GEM to support OpenGL ES. It mainly involves replacing the immediate mode functions and a few wrappers for defines which ES doesn’t use. We do this in OpenFrameworks.
The main problem, like everything, is who has the time to do it?
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On Mar 15, 2015, at 4:00 AM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
*From:*Cyrille Henry <ch@chnry.net mailto:ch@chnry.net> *To:*pd-list@lists.iem.at mailto:pd-list@lists.iem.at *Date:*March 15, 2015 at 2:47:02 AM PDT *Subject:**Re: [PD] Gem on Raspberry pi 2*
Le 15/03/2015 04:11, Simon Wise a écrit :
Apparently there is some support beyond Es, but not enough to run gem and as not at all documented.
i was to much optimistic and did not double check the informations i found announcing openGL support. thanks for the clarification. cheers c
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
yes, i know, but this is lot's of work. i just say that's it's not a mandatory operation for porting Gem to openGL ES
cheers c
Le 18/03/2015 03:27, Dan Wilcox a écrit :
The primitives and other immediate mode stuff can be implemented with VBAs, etc see https://github.com/openframeworks/openFrameworks/blob/master/libs/openFramew... which will work in older versions of GL as well as the current version.
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On Mar 17, 2015, at 7:50 AM, Cyrille Henry <ch@chnry.net mailto:ch@chnry.net> wrote:
it's not only openGL-ES, openGL 3.0 also depreciate the glBegin / glEnd loop.
I've got the impression that it's not a big deal for software compatible with opengl 3 or 4 to be compatible with openGL ES and being compatible with recent openGL version is important since lot's of new shader are available.
in the future, most primitives will have to be rewrited and then, they also be compatible with openGLES. or maybe they could just be ignored...
anyhow, would it be easy to build a GemES where all primitive using glbegin / glEnd would be removed? as long as gemvertexbuffer and shader are available, lot's of things can be done...
what i currently dreaming of is : if openGL available version is > 3 : adding a message to gemwin to specify the openGL version used to create the context. (this is possible since openGL remove functionalities in newer version) if a context is created with a openGL > 3, or openGL-ES, then drop support for all primitive that are not compatible. and add new object for new functionalities...
then, object like cube / circle etc could be ported as abstractions
so, my point is : if the only problem for porting Gem to openGL-ES is the primitives, then we should port Gem without primitives...
cheers c
Le 17/03/2015 15:03, Antoine Villeret a écrit :
we discuss that a few in the past and afair we conclude that mobile devices will support OpenGL sooner than an OpenGL ES Gem will arrived but maybe this not true anymore, maybe mobile devices will never support OpenGL and will stuck in ES, which is enough for them so in that way, i could be nice to upgrade Gem to run OpenGL ES.
Maybe we can grab some code from OFX to do that. But anyway, my 2 cent seems to not move forward that discussion so much...
-- do it yourself http://antoine.villeret.free.fr
2015-03-17 14:55 GMT+01:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
I would be totally *possible* to update GEM to support OpenGL ES. It mainly involves replacing the immediate mode functions and a few wrappers for defines which ES doesn’t use. We do this in OpenFrameworks.
The main problem, like everything, is who has the time to do it?
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On Mar 15, 2015, at 4:00 AM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
*From:*Cyrille Henry <ch@chnry.net mailto:ch@chnry.net> *To:*pd-list@lists.iem.at mailto:pd-list@lists.iem.at *Date:*March 15, 2015 at 2:47:02 AM PDT *Subject:**Re: [PD] Gem on Raspberry pi 2*
Le 15/03/2015 04:11, Simon Wise a écrit :
Apparently there is some support beyond Es, but not enough to run gem and as not at all documented.
i was to much optimistic and did not double check the informations i found announcing openGL support. thanks for the clarification. cheers c
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Antoine Villeret -
Cyrille Henry -
Dan Wilcox