<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The primitives and other immediate mode stuff can be implemented with VBAs, etc see <a href="https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/gl/ofGLRenderer.cpp#L1346" class="">https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/gl/ofGLRenderer.cpp#L1346</a> which will work in older versions of GL as well as the current version.<div class=""><br class=""><div class="">
--------<br class="">Dan Wilcox<br class="">@danomatika<br class=""><a href="http://danomatika.com" class="">danomatika.com</a><br class=""><div class=""><a href="http://robotcowboy.com" class="">robotcowboy.com</a></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Mar 17, 2015, at 7:50 AM, Cyrille Henry <<a href="mailto:ch@chnry.net" class="">ch@chnry.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">it's not only openGL-ES, openGL 3.0 also depreciate the glBegin / glEnd loop.<br class=""><br class="">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<br class="">and being compatible with recent openGL version is important since lot's of new shader are available.<br class=""><br class=""><br class="">in the future, most primitives will have to be rewrited and then, they also be compatible with openGLES.<br class="">or maybe they could just be ignored...<br class=""><br class="">anyhow, would it be easy to build a GemES where all primitive using glbegin / glEnd would be removed?<br class="">as long as gemvertexbuffer and shader are available, lot's of things can be done...<br class=""><br class=""><br class="">what i currently dreaming of is :<br class="">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)<br class="">if a context is created with a openGL > 3, or openGL-ES, then drop support for all primitive that are not compatible.<br class="">and add new object for new functionalities...<br class=""><br class="">then, object like cube / circle etc could be ported as abstractions<br class=""><br class="">so, my point is : if the only problem for porting Gem to openGL-ES is the primitives, then we should port Gem without primitives...<br class=""><br class="">cheers<br class="">c<br class=""><br class=""><br class=""><br class=""><br class="">Le 17/03/2015 15:03, Antoine Villeret a écrit :<br class=""><blockquote type="cite" class="">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<br class="">but maybe this not true anymore, maybe mobile devices will never support OpenGL and will stuck in ES, which is enough for them<br class="">so in that way, i could be nice to upgrade Gem to run OpenGL ES.<br class=""><br class="">Maybe we can grab some code from OFX to do that.<br class="">But anyway, my 2 cent seems to not move forward that discussion so much...<br class=""><br class="">--<br class="">do it yourself<br class=""><a href="http://antoine.villeret.free.fr" class="">http://antoine.villeret.free.fr</a><br class=""><br class="">2015-03-17 14:55 GMT+01:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>:<br class=""><br class=""> 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.<br class=""><br class=""> The main problem, like everything, is who has the time to do it?<br class=""> --------<br class=""> Dan Wilcox<br class=""> @danomatika<br class=""> danomatika.com <http://danomatika.com><br class=""> robotcowboy.com <http://robotcowboy.com><br class=""><br class=""><blockquote type="cite" class=""> On Mar 15, 2015, at 4:00 AM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote:<br class=""><br class=""> *From:*Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>><br class=""> *To:*pd-list@lists.iem.at <mailto:pd-list@lists.iem.at><br class=""> *Date:*March 15, 2015 at 2:47:02 AM PDT<br class=""> *Subject:**Re: [PD] Gem on Raspberry pi 2*<br class=""><br class=""><br class=""><br class=""><br class=""> Le 15/03/2015 04:11, Simon Wise a écrit :<br class=""><br class=""><blockquote type="cite" class=""> Apparently there is some support beyond Es, but not enough to run gem and as not at all documented.<br class=""></blockquote> i was to much optimistic and did not double check the informations i found announcing openGL support.<br class=""> thanks for the clarification.<br class=""> cheers<br class=""> c<br class=""></blockquote><br class=""><br class=""> _______________________________________________<br class=""> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list<br class=""> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list<br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">Pd-list@lists.iem.at mailing list<br class="">UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list<br class=""><br class=""></blockquote></div></blockquote></div><br class=""></div></body></html>