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 GEM-dev@iem.at 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