EGL_Wrap SDL2-GL4ES GL-Cube run time issue

Hi. As part of the requirements for Doom3, Hunno's EGL Wrapper library is needed.

I took the liberty of also installing the SDK portion so that I can look into the examples.

All seem to run fine part from the SDL2-GL4ES example (which is the one I am particularly interested in learning from).

There is one example in there and it is the GL-Cube.

I renamed the already built binary and ran make again to compile on my machine. Compilation and linking is okay, but at run time:


And, the crash log:


This also happens when directly invoking the original binary.

@rjd324
I can't say how mature Huno's EGL are for now, but when i checked 2 years ago, it did have some issues on which Huno working. It was simple try to port something over EGL and some things just didn't works correclty. I know Huno did work on it and maybe those issues gone, but, if i were you, i better didn't refers to another layer which we have a lot already, and if you want to write your own code, then use SDL2 + Ogles2 directly. And if you do ports, then use SDL2 + GL4ES.

If you want to port EGL + SDL2 + OpenGL code, then probabaly it will be better to remove EGL code and replace it with anything else, because as of now, we didn't have proper, well-tested and mature EGL port.

@rjd324

Hello,

Excuse me for my somewhat late response.
Yes as Kas1e said there were small problems at the time via egl_wrap to initialize native egl but now it works correctly (a triangle example proves it).
As for the sdl1 and sdl2 part, everything also works wonderfully via my library (the examples are also there to prove it).
On the other hand, it is necessary to respect the order of the code
As for the example, it should work at compile time
For my part, I have not yet migrated to a gcc higher than 4 (for lack of time) and I think that your compilation is with a higher gcc, hence the problem. Try a lower version and tell me.

HunoPPC

Hi all,

Is there a reason why egl_wrap is a shared object?

@rjd324

hello, yes of course … to facilitate its update without generating a new executable each time

HunoPPC

Hey, sure. But can we also have a static version?

I think I read in one of the PDFs that it is not a good idea on the Amiga to link to so and static at the same time. When we use the --dyn option, then everything has to SO, right?

There are a lot of people who are developing that do not use SO.

I was just wondering about that.

Actually, I am wrong. That option only says use SO in preference:
Quote:

And, the part about ideally not using both static and dyn is due to fpic. But, nothing stops you.

@rjd324

I didn't know about this warning about using both types of library. I use static libraries and shared objects simultaneously in all my projects on a daily basis and I have no problems.
Just in your makefile you declare the statics first and last your shared objects and everything goes.
For the moment it is not planned to make a static library but I could do a test for you so that you can test.

HunoPPC