Problems trying to compile Ren'Py


sebt3 said:
doragasu said:
Is libGL only compatible with OpenGL and not with OpenGL ES?
Click to expand...
that's it.


Beside libglew depend on libGL. (glew mean GL Extention Wrapper ;) I've seen some equivalent for ES though
Click to expand...

I supposed that, but since libGL is included in the SDK, I thought it was not useless XD. Now I know it is...


OK. I think I'll try to clean EVERYTHING and build it again from the beginning...
 
Last edited by a moderator:
doragasu said:
I supposed that, but since libGL is included in the SDK, I thought it was not useless XD. Now I know it is...
Click to expand...
There used to have a GL inside yactfeau, it was mesa (software implementation of GL, so not useless, just painfully slow) I now have removed it. I guess Ivanovic have kept it in his own toolchain.
 
The libGL in your toolchain, sebt3 doesn't even seem to be mesa. It just doesn't work ;)
 
Last edited by a moderator:
I asked the author again, and he told me glew is not needed for the GLES version. To get GLES support, I was compiling the Android path (-DANDROID added to CFLAGS), and the author also told me I just can't use the Android path :(


It looks like this is going to be more difficult than I thought. I'll continue trying things, but I think I'm going to need some help here. Mainly because there's some knowledge needed about Python distutils, and as I wrote in other posts, I know almost nothing about Python.
 
You have to change the source a bit maybe.


Try to change #include GL/gl.h into #include GLES/GL.h and change the linkerflags -lGL to -lGLES_CM .


I don't know if that is helpful for python, but in C and C++ it works.


Also you may have to create your own EGL context, but as said, I don't know how this works with phyton...
 
Last edited by a moderator:
Ren'Py is prepared to work with GLES, but it looks like that the GLES options are tied to the Android port, so there's stuff that breaks things if you enable the Android port to get GLES working.


That said, playing a bit with setup.py and setuplib.py, I managed to make a semi-working build. Now games can be started and played, but with the following drawbacks:


- It's still working in software mode so...


- Performance is very slow and effects (for example soft transitions) don't work.


- Sound is not working :blink:


Even though GLES is still not working, I think I have partially solved the problem. Before, the problem was renpy was trying to load libGL.so. Now pygame is who is trying to load libGL.so, so I suppose the problem is I need to recompile pygame (and maybe also SDL?) with GLES support. Is this difficult? Any help about this task is very appreciated.


I don't know what's the problem with sound. The log file shows no errors about sound. The only thing that I think might be causing this problem is that I changed Ren'Py build script to compile SDL without PulseAudio support, because it was causing errors. I supposed Pandora has not PulseAudio support. Am I right?


Three new screenshots:


shot3.png


shot4.png


shot5.png
 
I think you should do it like with all the other ogles ports:


Don't try to use sdl_opengl or pygame_opengl (or whatever this is called), but use the eglport by pickle and setup your project to work with it:


Here might be some useful information:


http://pandorawiki.o...to_GLES_from_GL


Edit: I don't think Pandora has pulseaudio. If possible, use the alsadriver.


Edit: the sdl on the Pandora doesn't have opengles support.


The first sdl, that introduces that is 1.3 afaik.
 
Last edited by a moderator:
Eglport by pickle does the same as sdlgles.


You can download it at sebt3's page:


http://sebt3.openpandora.org/buildtools


It has to be included in the build, as stated on the link in my previous post.


Also not sdl needs modification here, neither does pygame. The game itself needs to be modified to create an egl context instead of the opengl one.
 
Let's see if I understood you properly:


1.- Using eglport, I have to create an EGL context as described in the Wiki.


2.- I have not to modify SDL, the modifications must be done in the game (in this case, in the game engine: Pygame).


Now the questions:


3.- Besides adding the EGL context, shouldnt I also convert a lot of code like described in the wiki?


4.- Shouldn't I also modify pygame to link it to GLES instead to GL?


Having a quick look to the Python/pygame subforum, it looks like nobody has coded anything for the Pandora using GLES and pygame...


EDIT: It looks like there's also a SDL 1.3 version by Cpasjuste that works with GLES:


http://pandorawiki.org/Combining_OpenGL_ES_1.1_and_SDL_to_create_a_window_on_the_Pandora


I'm extremely confused... I'm starting to think that I'll not port this to GLES.
 
Last edited by a moderator:
I am sorry, but you are in a field here, nobody else seemed to try before.


So I can only tell you what I know about GLES and SDL without pygame:


1+2: Correct!


3: You don't need to convert all this stuff, if the game is already written with gles in mind. Only if you have a normal opengl game and want to rewrite it to use gles instead.


4: I think that could be the case, but as said, not sure how that works with pygame.


If there is a SDL 1.3, that supports gles, then that won't solve your problem with pygame most likely... I tjust means, that there is a way in it to create an EGL context already without need for eglport.


Sorry, that I can't tell you more about this. Maybe there is somebody, that has done something with pygame and gles before and can help.
 
I have found a (maybe) interesting fact. I have grep the whole library directory searching for "libGL.so", and the only matches I have found are in libSDL. There are no coincidences in pygame libraries, so I'll assume pygame doesn't directly deal with GL stuff, and that must be done in the game. An additional grep in the .o files of the SDL build, gives me a match in only one file: SDL_x11gl.o.


Having this in mind, for the first test, I'll assume the most favorable (for me) scenario: that as Ren'Py for Android has been created with GLES in mind, it also creates the EGL context. If that's the case, and I'm understanding correctly all these stuff about OGL/OGLES, shouldn't it work if I somehow remove this dependency with libGL?


@mcobit: don't worry, your help is greatly appreciated and you're giving me really valuable hints and tips!


EDIT: Tried to compile SDL without OpenGL support but that didn't help. Now the error I get from Ren'Py is: 'X11 driver not configured with OpenGL'.


It looks like I'll have to go the hard way and dig through Ren'Py sources.
 
Last edited by a moderator:
Maybe you should try to use the sdl 1.3 with oglsupport...
 
mcobit said:
Maybe you should try to use the sdl 1.3 with oglsupport...
Click to expand...

I have just tried that. More problems :( . SDL 1.3 compiles, but when trying to compile anything that depends on it (i.e. SDL_ttf) I get a whole lot of errors when linking like this:



Code: 
/home/jalon/Pandora/renpy/renpy-deps/install/lib/libSDL.so: undefined reference to `XPending'

/home/jalon/Pandora/renpy/renpy-deps/install/lib/libSDL.so: undefined reference to `dlclose'


If I grep the functions in the errors, their names are found in the library, so I don't know what's happening. Maybe the libraries aren't properly installed (I just copied them to the install directory, because the provided Makefile didn't install them).
 
Last edited by a moderator:
This is frustrating. I have tried with this version of SDL 1.2.13 with GLES support and got everything to compile. Now the error Ren'Py spits is:



Code: 
I'm sorry, but an uncaught exception occurred.


After initialization, but before game start.

error: Could not retrieve EGL function eglGetDisplay


-- Full Traceback ------------------------------------------------------------


Full traceback:

  File "/media/IORI_PANDORA/ports/renpy-6.13.7/renpy/bootstrap.py", line 276, in bootstrap

    renpy.main.main()

  File "/media/IORI_PANDORA/ports/renpy-6.13.7/renpy/main.py", line 343, in main

    renpy.display.core.Interface()

  File "/media/IORI_PANDORA/ports/renpy-6.13.7/renpy/display/core.py", line 1149, in __init__

    self.set_mode()

  File "/media/IORI_PANDORA/ports/renpy-6.13.7/renpy/display/core.py", line 1356, in set_mode

    if draw.set_mode(virtual_size, physical_size, fullscreen):

  File "/media/IORI_PANDORA/ports/renpy-6.13.7/renpy/display/swdraw.py", line 760, in set_mode

    self.screen = pygame.display.set_mode((scaled_width, scaled_height), fsflag, 32)

error: Could not retrieve EGL function eglGetDisplay


Linux-2.6.27.46-omap1-armv7l-with-glibc2.4

Ren'Py 6.13.7.1646



But the symbol is defined:





Code: 
$ arm-angstrom-linux-gnueabi-nm -Dg /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/libGLES_CM.so | grep eglGetDisplay

		U IMGeglGetDisplay

0003e968 T eglGetDisplay

$ arm-angstrom-linux-gnueabi-nm -Dg /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/libGLES2D.so | grep eglGetDisplay

		U eglGetDisplay


EDIT: I have found something strange, and maybe related to the problem. If I run from my PC "arm-angstrom-linux-gnueabi-nm libGLES_CM.so", it lists properly the symbols, including the offending function. If I run "nm libGLES_CM.so" from my Pandora, it says there are no symbols defined! If now I copy this library that is supposed to have no symbols from my Pandora to my PC, and run arm-angstrom-linux-gnueabi on it, symbols are listed!


Even more strange, if I run from my Pandora "nm libGLES2D.so", symbols are also listed!


Is this significative??? Is there a problem with my libraries or with nm in my Pandora???
 
Last edited by a moderator:
I have browsed the code in SDL that loads the library and is causing the error. It looks like the library is loaded, but dlsym fails to load the function pointer (maybe because of the same problem that makes nm fail?). The related code inside SDL_x11gles.c:



Code: 
[...]


/*

*  A macro for loading a function pointer with dlsym

*/

#define LOAD_FUNC(NAME) \

*((void**)&this->gles_data->NAME) = dlsym(handle, #NAME); \

if (!this->gles_data->NAME) \

{ \

SDL_SetError("Could not retrieve EGL function " #NAME); \

return -1; \

}


/* Passing a NULL path means load pointers from the application */

int X11_GLES_LoadLibrary(_THIS, const char* path)

{

[...] Removed the code that loads EGL library using dlopen and errors if something goes wrong


/* Load new function pointers */

LOAD_FUNC(eglGetDisplay);


[...]



Pastebin of the complete X11_GLES_LoadLibrary function: http://pastebin.com/qFC5jj50



There's something about the macro that loads the functions that I don't understand. It's the way it calls dlsym. dlsym takes two parameters: the library handle and a null terminated string with the symbol name. Watching the call to dlsym and making the substitution of NAME with eglGetDisplay, the call would be something like:





Code: 
*((void**)&this->gles_data->eglGetDisplay) = dlsym(handle, #eglGetDisplay);


I have never seen the syntaxis of "#eglGetDisplay" before... What does it mean? Does it convert eglGetDisplay in a const null terminated string?


Also, can the problem with dlsym be related to the prooblem with nm being unable to list simbols in the Pandora?
 
Last edited by a moderator:
You must log in or register to reply here.

Similar threads

Aninhumer
Anpan!
Replies
2
Views
1K
DasFool
D
British
Portability of Ren'Py
Replies
1
Views
4K
Aninhumer
Aninhumer
pmprog
Cross Compile Libraries
Replies
1
Views
1K
sebt3
sebt3
mcobit
Trying To Compile Custom V4L
2
Replies
20
Views
9K
Hansi
Hansi
B
GP32 Trying To Compile C++ With Mrmirkos Sdk
Replies
0
Views
1K
bobintrees
B
Back
Top