Sneaky Youtube Peek At Python Accessing Gles


chris_c

Member
Joined
Jun 25, 2010
Messages
393
Age
55
Its nothing special just yet! its very early days...

http://www.youtube.com/watch?v=IZf4YGpTJrM

I'll actually release a module for people to play with, when I've put together a few more utility routines and some decent examples.

Because I'm creating a window for the context I might have to do some routines for input handling too, but I may well investigate getting a Xlib handle from an SDL created window which means I can concentrate on just GLES - I don't know just yet...

I'll investigate GLES 2.0 at a later date but I had some problems creating a GLES 2.0 context with python, so I want to do some experiments in C which means its going to have to wait till I set up a development environment on the Pandora, and I'll wait till I'm happy with the 1.1 module too!

Enjoy!
 
what framerate? :)

jeff

See, what I did was use ctypes to call a .so of my own, and it does all the gles stuff in itself; really a cheap way, since I didn't yet have time to wrap up all the gles stuff myself :) I'm watching closely :)
 
if I'm honest its not so much a wrapper as a bunch of ctypes stuff to allow you to directly access the gles lib directly but in
a more convenient way that without any support....

There's a few utility routines and a bit of a stumbling block with input which I know I resolve can one way or the other.

I've no idea what fps its running at, I've not even bothered looking bare in mind thats a whole 3 triangles so any speed test is meaningless

even if python was very slow (which it aint) bare in mind its the 3d hardware doing most of the heavy lifting - each frame is just python making a few
calls to set pointers etc

I've checked that vertex colouring, texturing, and lighting is all working and hunky dory, so I'm going to leave example coding alone and concentrate
on stuff that I feel is stopping me release it...
 
Thats what a wrapper is :)

python is surprisingly quick for being interpreted, but its absolutely terrible at number crunching (especially with no fpu handy.) My biggest problem is crunching a few thousand numbers to generate a scene, really really sluggish. (But then, to be fair, I'm doing a brute force tesselation and fractal terrain generation, which could entirely be redone as shader scripts, but I don't want to figure GLSL out yet :)

Seems like a few thousand triangles from python->gles via ctypes is nothing though, from my experience.

jeff
 
Are you working at all with PyOpenGL? I've heard mutterings about them doing ES bindings for ages, but I haven't seen any. They're also ctypes based, so I imagine they would love to see, and perhaps incorporate your code.
 
Tempel said:
Are you working at all with PyOpenGL? I've heard mutterings about them doing ES bindings for ages, but I haven't seen any. They're also ctypes based, so I imagine they would love to see, and perhaps incorporate your code.
Hell no! :D its just me and pure python hitting the xlib library and the gles 1.1 lib

I'm avoiding using any object oriented interface for it because lets face it a C (as opposed to a c++) lib isn't really object oriented and the two methodologies don't always fit well together. In addition its probably faster too :D

I've decided that I'll be providing a simple mouse and keyboard handler as its kind of wrapped up in the act of creating the xlib window and context...
 
Last edited by a moderator:
This is really great news - it will definitely make it a lot more feasible to use the Pandora itself to do onboard development of interesting 3D apps .. well done, and please accept a lot of encouragement to see this project through to completion! :) I will definitely be checking it out once you publish it with mouse and key handling, and I can think of some great uses for this, so I hope to be playing with it soon ..
 
torpor said:
This is really great news - it will definitely make it a lot more feasible to use the Pandora itself to do onboard development of interesting 3D apps .. well done, and please accept a lot of encouragement to see this project through to completion! :) I will definitely be checking it out once you publish it with mouse and key handling, and I can think of some great uses for this, so I hope to be playing with it soon ..
currently slogging through xlib event loop which is now working - but get this key repeats generate loads of key pressed and released events while the key is down! horrid! I'll have to do something about that!!!!

what I'm aiming for is some globals an array of bools 1 for each key ie if (isKeyDown[keycode]) .... the same for the mouse "button" and a mouse x & Y var, once a frame you'll need to call something like utilsPollEvents() to keep them upto date...
 
Last edited by a moderator:
It seems like PyOpenGL doesn't currently support GLES, and their mailing lists seem totally dead. Need to look into it more, but its ont hard to just not use PyOpenGL so I dind't get back to that yyet myself .. but yeah, maybe chris_r's work can drop in there :)

PyOpenGL doesn't add any crazy interfaces, its just the same approach, adding the constants and ctype calls to the libs.

jeff
 
Back
Top