This is great! Looking forward to the result. .hc
On Feb 1, 2012, at 12:30 PM, dmotd wrote: > hi gem folks, > > i've had a bit of free time to begin porting gem to opengl-es. > > i'm building and testing with a nokia-n900/RX51 tablet - a debian based > arm arch which supports both opengl-es 1.1 common and opengl-es 2.0. > > initial hacking is concentrated on opengl-es 1.1, which is generally > compatible to the opengl 1.0 spec. opengl-es 2.0 uses shaders to replace > fixed functions so there is a lot more work involved in replacing core > gem functions. > > i'm using the egl spec for windowing/surface/buffer support, it is cross > platform (although afaik apple uses its own modification 'aegl'). it > provides basic functionality for reading and writing gl functions to > buffer (along the lines of glx), and like glx still relies on operating > system apis to supply other interfaces (keyboard / mouse etc). > > so far: > -- > cloned gem git, checkout 0.93 tag, created es branch. > > using glues for basic (incomplete) glu functionality > > using libglutes for basic (incomplete) glut functionality > > added additional autoconf tricks to find and test libraries > > merged the latest git ES branch of GLEW which has experimental support > for GLES/EGL > > added egl drop in for GemWinCreate > > successful build against pd-0.43 using enable-Controls and others > disabled. > -- > > reports: > -- > libxxf86vm doesn't seem to work properly on the tablet, so for the time > being the window modelines are hard coded. there are some other window > manager hints that are specific to the device too. > > gemwin successfully creates the egl window buffer and rendering context. > > gem crashes when glClearDepthf and glFrustumf are called (both are > floating-point variations to the base GL functions and part of the GL-ES > spec). furthermore looking at the output of 'nm -C Gem.pd_linux' shows > that these functions are not present in the compiled lib, what does this > mean? > > commenting these functions out allows the gemwin to complete init and > create successfully. a call to render causes a crash somewhere in the > rendering chain (GemMan::render), but i have had little success > debugging this issue. > -- > > notes: > -- > i'm developing with an eye on the raspberry pi project which should > bring affordable opengl-es architecture to a small form factor, perfect > for installations of (audio)visual artwork - but there's no reason why > any recent (jailbroken) mobile/tablet technologies wouldn't be > applicable for creative repurposing. > > before anyone get's excited, the apple 'app store' is still afaik not > compatible with gpl code, so it is unlikely there will be a 'rjdj' style > app using gem, or likewise any gem based vj app, i don't think the same > can be said for google's android platform, but i'm not a user or > developer of said platform (or the fruit for that matter). > > i am coding on a linux-amd64 pc, cross-compiling in scratchbox and > testing on the device, using git/scp as a go-between.. this is a bit > cumbersome/inefficient - can anyone suggest a virtual machine image > (linux based) that provides a graphical gl-es environment and a minimal > editor/ide to build and test with? > -- > > i'll keep everyone up to speed as i make developments, and if anyone can > replicate my dev environment and wants to contribute i'll happily push > to a public git sooner rather than later. > > cheers, > dmotd > > > _______________________________________________ > GEM-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/gem-dev ---------------------------------------------------------------------------- "Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
