[GEM-dev] gem port to opengl-es - initial developments..

[dmotd]

On Thu, 2012-02-02 at 10:14 +0100, IOhannes m zmoelnig wrote:
> On 2012-02-01 18:30, dmotd wrote:
> > hi gem folks,
> > 
> > i've had a bit of free time to begin porting gem to opengl-es. 
> 
> kjul!
> 
> > cloned gem git, checkout 0.93 tag, created es branch.
> 
> any reason why you did not use master?

i thought i'd start at a stable fixed point, so i wouldn't be getting
too mixed up with experimental features in a moving target. i think this
will get me into trouble later, but honestly i didn't know how far i
would persist.

> 
> > added egl drop in for GemWinCreate
> 
> in master is an (experimental) new class of objects that implement
> window-handling rather than using the olde fixed GemWinCreate (look at
> src/Output).
> currently only OSX-10.6 builds make use of that, but the more it gets
> tested the sooner it will be the one and only method to create windows.

ahh yes, i actually i started implementing this feature with egl before
i realized that it wasn't actually being used, so it should be mostly
ready anyway. 

i'm still jumping through hoops due to be some issues with a sloppy
nokia gles/egl implementation on this hardware which is a bit
infuriating (and bug reports are increasingly getting marked with
WONTFIX everywhere which i assume has a lot to do with nokias recent
relationship with MICROS~1).

> > 
> > 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
> 
> in the future (see above), those calls will not be hardcoded into
> GemManager any more, but instead are called from an abstraction (gemwin.pd)
> 

good to know, future Gem is looking exciting! :)

when i get some more interesting results i'll attempt a merge into
master.


> > floating-point variations to the base GL functions and part of the GL-ES
> 
> so they should be there but are not?

exactly, see below..

> 
> 
> > 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?
> 
> what do you mean by "not present"?
> they are most likely "undefined", as they will be imported from GL-ES

after digging through gdb it occurred to me that there must be a problem
with how glClearDepthf was being referenced, and found that the gles
library was not being located in the glew src (libGLESv1_CM.so instead
of libGLES_CM.so on this environment) - rebuilt, stepped through
windowInit and confirmed that finally the function was now being
called.. my guess is that glew had been defining it NULL. glFrustumf is
happy now too, *phew*

> > 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 haven't found a useable one yet.
> in theory, there are android-for-eee images availabe, which should , and
> there is myOS[1], which i haven't tried for some time (though it seems
> to be a dead project anyhow) but it never worked with my nvidia-card...
> 
> if you have success in getting a simple setup for GL-ES development,
> please let us know!

this looks promising:
http://wiki.meego.com/ARM/Meego_on_Qemu

meego was to be the replacement for maemo before it got canned by nokia
(to become mer/tizen)

it looks like it uses native gl with a gles wrapper (dgles2) but i'm not
sure if it still retains support for gles 1.1 (dgles?)

the qemu part appears to emulate the n900 hardware.

if i get time i'll try to set it up and post results.

> > 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.
> 
> oh please!

sure, i'll try to get it rendering tonight and throw the code up on
github.

cheers.
dmotd