[PD] Gem on Raspberry pi 2

[Cyrille Henry]

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 at gmail.com <mailto:danomatika at 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 at lists.iem.at <mailto:pd-list-request at lists.iem.at> wrote:
>>
>>     *From:*Cyrille Henry <ch at chnry.net <mailto:ch at chnry.net>>
>>     *To:*pd-list at lists.iem.at <mailto:pd-list at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>     UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>