Build without EGL or X11

[kas1e]

Want to port gl4es to some obscure platform, which have no EGL or X11, but its own API for creating context and co, and have some questions:

Lately port REGAL and it wasn't as good as i expected. Simple things do not works as expected while others do. So i want to try gl4es as it seems only one project which in develop and looks good enough.

So, i can buld Regal as static library, just with: -DREGAL_SYS_ES2=1 -DREGAL_STATIC_ES2 -DREGAL_SYS_X11=0 -DREGAL_SYS_GLX=0 -DREGAL_SYS_EGL=0

Then, in GL programm i just change include <GL/gl.h> on include <GL/Regal.h>, and link binary against -lgles2 , and all works.

So i want to do the same for gl4es. Is it possible ? All i need, its static library, which will worry about ogl calls and transfer them to ogles context (which i create myself, by own api) , without reling in any way on X11 or EGL (as i can for myself create windows, context and handle buttons and stuff).

Thanks in advance for help !

[kas1e]

@ptitSeb Line 52 should be: IExec->DropInterface((struct Interface *)IOGLES2); Checking what wrong with MAP

[ptitSeb]

I have fixed all this (I think) already, with latest commit.

[ptitSeb]

Mmmm, looking at the includes now. I think the wrapper will not work yet (the IOGLES->glXXX need IOGLES as fist parameter)., I'll do something like the sdlwrapper then.

[ptitSeb]

Mmmm, in fact, looking at inline4/ogles2.h it should work!

[kas1e]

Checked latest amigaos.c : it miss getInterface() function, you can grab it here (at top): http://kas1e.mikendezign.com/aos4/gl4es/os4_gles_example_for_ptitSeb.c

Also #include , for strcmp

[kas1e]

Also on linking stage gl.c still complain about missing dlsym() from functions glIsEnabled, glDisableClientState, glEnableClientState and some otheres

[kas1e]

Still complain : src/agl/amigaos.c: In function 'os4OpenLib': src/agl/amigaos.c:22: warning: passing argument 2 of 'IExec->GetInterface' from incompatible pointer type src/agl/amigaos.c:22: note: expected 'struct Library ' but argument is of type 'char '

But i think we can keep it as it at moment, warning probably not critical and will work.

Now to build all the stuff and first run !

[kas1e]

Ok that warning go with your latest commit, but, still problmes with dlsym():

$ ppc-amigaos-gcc test.c libgl4es.a libgl4es.a(gl.o): In function glDisableClientState': gl.c:(.text+0x2124): undefined reference todlsym' libgl4es.a(gl.o): In function glEnableClientState': gl.c:(.text+0x2268): undefined reference todlsym' libgl4es.a(gl.o): In function glAlphaFunc': gl.c:(.text+0x2d98): undefined reference todlsym' libgl4es.a(gl.o): In function glColor4f': gl.c:(.text+0x5190): undefined reference todlsym' libgl4es.a(gl.o): In function glNormal3f': gl.c:(.text+0x56c4): undefined reference todlsym' libgl4es.a(gl.o):gl.c:(.text+0x70fc): more undefined references to `dlsym' follow collect2: ld returned 1 exit status

[ptitSeb]

Ok, I fixed that warning. It will not work without the fix!

Also, I added aglXXXX function (hopefully). That means, in your program, you #include "agl/agl.h" from gl4es and you can just use the aglXXXX function for context creation and swapbuffer directly. No need to include any OGLES2 function now, you don't need to open that lib also, gl4es will take care of it.

[kas1e]

Sadly, but dlsym() errors still here :( :

$ ppc-amigaos-gcc test.c libgl4es.a libgl4es.a(gl.o): In function glDisableClientState': gl.c:(.text+0x2124): undefined reference todlsym' libgl4es.a(gl.o): In function glEnableClientState': gl.c:(.text+0x2268): undefined reference todlsym' libgl4es.a(gl.o): In function glAlphaFunc': gl.c:(.text+0x2d98): undefined reference todlsym' libgl4es.a(gl.o): In function glColor4f': gl.c:(.text+0x5190): undefined reference todlsym' libgl4es.a(gl.o): In function glNormal3f': gl.c:(.text+0x56c4): undefined reference todlsym' libgl4es.a(gl.o):gl.c:(.text+0x70fc): more undefined references to `dlsym' follow collect2: ld returned 1 exit status

As for aglXXXX functions, maybe i miss the point, but i can use them from users code directly as well, no problems there , i can just extern interface , so it will be taken from libgl4es.a . I only will include <proto/gles2.h> and will use it all as usuall. Why we need to worry about them ?:)

[ptitSeb]

For the dlsym errors, as I changed loader.h, you need to rebuild all files. The dlsym error are still there?

For the aglXXXX function, you can indeed use the ogles2 function, but you can also just use gl4es, completly masking ogles2 interface. If you use aglXXX funciton from ogles2, be sure to NOT use any glXXXX function from ogles2, as this will just break things... That's why I prefer to have the option of only using gl4es, without reference to ogles2 that will be used under the hood. (also, I have added some code in aglSwapBuffer()).

[kas1e]

Yes i rebuilded all from scratch, and dlsym errors still here :(

[ptitSeb]

Ok, removed the last dlsym (I hope) in loader.h for AmigaOS4...

[kas1e]

Almost ! :) Last 2 in the glx.c :)

[kas1e]

Yes ! All rebuilded, library done, test case builds just like : ppc-amigaos-gcc test.c libgl4es.a

Now, after running i have:

LIBGL: Initialising gl4es LIBGL: v1.0.5 build on Feb 17 2018 12:36:08 LIBGL: Using LES 2.0 backed LIBGL: Hardware test disabld, nothing activated... LIBGL: warning, gles_glGetIntegerv is NULL

But that probably expected for such a "non working" test case ?

Can i rebuild gl4es with some more debug output ? (if there is any)

[ptitSeb]

Mmmm, that's odd. I have added a printf when loading OGLES2 driver. It should printed before the "gles_glGetIntegerv is NULL". Also that line is not a good sign, and a confirmation that GLES2 driver is not loaded. (in fact, it should be there before the "Hardware test disabled" in fact)

[kas1e]

We even didn't have " printf("LIBGL: OGLES2 Library and Interface open successfuly\n"); "

[kas1e]

Give me some minuts, i will just download latest and rebuild everything, probably messed something somehwere ..

[kas1e]

Rebuild everyhting from scratch, that what i have:

LIBGL: Initialising gl4es LIBGL: v1.0.5 build on Feb 17 2018 14:27:30 LIBGL: Using GLES 2.0 backend LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Hardware test disabld, nothing activated... LIBGL: warning, gles_glGetIntegerv is NULL

And then crash.

[ptitSeb]

commit 9a6d106c7c591e8ddaa78cfd772c0d83283215be should have fixed the "gles_glGetIntegerv is NULL" warning (and probably the crash too).

[kas1e]

With that one we have:

LIBGL: Initialising gl4es LIBGL: v1.0.5 build on Feb 17 2018 14:27:30 LIBGL: Using GLES 2.0 backend LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Hardware test disabld, nothing activated...

And the crash in the Initialie_gl4es() -> NewGLState()

[kas1e]

I.e. no words about "LIBGL: warning, gles_glGetIntegerv is NULL". Probably we going futher now..

[ptitSeb]

I assume the crash is because calling glGetIntegerv with no context, the OGLES2 driver probably doesn't like that. I'll try to compensate.

[ptitSeb]

Latest commit tries to mitigate that. I hope it works now. Later, I think I will have to add better context creation in the aglXXXX function too, like with the glX functions

[kas1e]

But as we create context from user's code, then we cant call any ogles functions before actual gl calls from user's code starts

[ptitSeb]

Yes, that's why, on Linux/EGL, I create a context with a PBuffer to query GLES driver. I'm not sure this things exist on AmigaOS, so lets just try to skip that for now.

[kas1e]

Ok, we going much futher now. With that test case:

int main() { glBegin ( GL_POLYGON ); glEnd(); }

We have:

LIBGL: Initialising gl4es LIBGL: v1.0.5 build on Feb 17 2018 14:27:30 LIBGL: Using GLES 2.0 backend LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Hardware test disabled, nothing activated... LIBGL: Targeting OpenGL 2.0 LIBGL: Current folder is: NO NAME:gl4es LIBGL: OGLES2 Library and Interface closed

And programm exit fine. Good !

Then, i trying simple that:

int main() { glClearColor(0.4f, 0.3f, 0.3f, 255.0f); }

And it crashes (as expected, as no context there), in the : gl4es_glClearColor.

So, i tried then a very simple test case where i create window, context and all usuall stuff. Only that i don't open ogles2.library / interface, as its in the libgl4es.a already. Test case are: http://kas1e.mikendezign.com/aos4/gl4es/test2.c

And then, it crashes the same, in the first glCall (i.e. also gl4es_glClearColor().

Now we at point where we almost made it work probably ! Now to understand is it not having context make it crash, or something else .. Or maybe i still need to open ogles2.libary (again) and share context somehow ..

[ptitSeb]

I think there maybe an issue with teh way I wrap OGLES calls.

I'll copy the SDL wrapper way of doing it, it may improve things....

[kas1e]

Yeah, probably it should crash later when no context found, not in the gl4es_glClearColor, but in the glClearColor() from ogles. But as it crash early, then probably you right ..

[ptitSeb]

is it better with commit 8fa9cf0c7d96fa453753fd0df4b9426ee1ec0237 ?

[kas1e]

src/agl/amigaos.c: In function 'os4GetProcAddress': src/agl/amigaos.c:771: error: 'AmiaglCreateContext' undeclared (first use in this functio src/agl/amigaos.c:771: error: (Each undeclared identifier is reported only once src/agl/amigaos.c:771: error: for each function it appears in.) src/agl/amigaos.c:772: error: 'AmiaglCreateContextTags' undeclared (first use in this fun src/agl/amigaos.c:773: error: 'AmiaglDestroyContext' undeclared (first use in this functi src/agl/amigaos.c:774: error: 'AmiaglMakeCurrent' undeclared (first use in this function) src/agl/amigaos.c:775: error: 'AmiaglSwapBuffers' undeclared (first use in this function) src/agl/amigaos.c:776: error: 'AmiaglSetBitmap' undeclared (first use in this function)

But i commented out those internal functions at end, and:

test1 where just pure call to glClearColor: don't crash ! Jus texit , good.

And, test2 : http://kas1e.mikendezign.com/aos4/gl4es/test2.c

Works (yeah!) , but didn't draw quad. But that mean that context works!

I.e. it result is: http://kas1e.mikendezign.com/aos4/gl4es/gl4es_first_render.jpg

While should be: http://kas1e.mikendezign.com/aos4/Regal/quads/quad_int_short.jpg

But , pretty possible that shaders didn't works (our shader's in gles2 didn't cope with arrays at moment, so if gl4es for that test create shaders with arrays that may be issue). Or, shader may fail just by any reassos .. Is there any ability to "dump" what shaders was create by gl4es for that exactly example ?

Btw, THANKS A BUNCH anyway :) You do a looot just to make support of platform you don't need :)

[ptitSeb]

If you want to see the shader generated for the quad, uncomment line 8 of src/gl/shaderconv.c

Then for each shader, you will see the original shader (even the one generated to emulated the fixed pipeline), and the GLES2 converted shader.

[ptitSeb]

Also, it would be interresting to just validate there is some drawing. You can also uncomment line 791 of src/gl/list.c. The glBegin()/glEnd() will be drawn in that draw_renderlist(...) function.

[kas1e]

Ok, added both debug outputs, and that what we have: http://kas1e.mikendezign.com/aos4/gl4es/debug_info.txt

Will try now to check shaders if they works at all

[ptitSeb]

Looks good to me. The vertex shader used is

#version 100
precision mediump float;
precision mediump int;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
// FPE_Shader generated
// ** Vertex Shader **
// ligthting=0 (twosided=0, separate=0, color_material=0)
// secondary=0, planes=000000
// texture=00000000, point=0
varying vec4 Color;

void main() {
gl_Position = _gl4es_ModelViewProjectionMatrix * _gl4es_Vertex;
Color = _gl4es_Color;
// texturing
}

and the Fragment is

#version 100
precision mediump float;
precision mediump int;
// FPE_Shader generated
// ** Fragment Shader **
// lighting=0, alpha=0, secondary=0, planes=000000, texture=00000000, texformat=00000000 point=0
varying vec4 Color;
void main() {
vec4 fColor = Color;
gl_FragColor = fColor;
}

[kas1e]

@ptitSeb Sorry for lame question, but is second versions of shaders from log uploaded to GLES in end ? I mean in log there is 2 vertex shaders, and 2 fragment ones. I think before that there should be just 1 vertex and 1 fragment generated for our code, and then uploaded to GLES2.

Also i see there some lines with just ":" at begining, is it mean anything ?

[ptitSeb]

There are 2 version because it's the log of "ShaderConv". So 1st version is the original "full OpenGL" shader, and the 2nd version is the converted shader that is sent to GLES2 driver. I have copied the shader that are sent.

[ptitSeb]

Can you also try something: in your test program, after IOGLES2->aglMakeCurrent(ogles_context); can you make a call to glViewport, like with glViewport(0, 640, 480, 0); ? It's just to test if, by any luck, the fact that the glstate is created without a context can be an issue....

[kas1e]

Aha, thanks for explain.

Checked both shaders in glslangvalidator and in with our shaders's code from ogles - they both fine, yes.. Uhm ! I was sure it's shaders .. What else it can be then.. Is that line looks ok too ?

draw_renderlist 0x67f0e718, gl_batch=0, size=4, mode=GL_TRIANGLE_FAN(GL_QUADS), ilen=0, next=0x0, color=0x67f0e8c8, secondarycolor=0x0 fogcoord=0x0

[ptitSeb]

Yes that line is fine. It mean it's going to draw a renderlist (wich is fine, because glBegin()/glEnd() get converted to renderlist). The size is 4 (fine with your Quad), the drawing mode is GL_TRIANGLE_FAN, but the original mode was GL_QUADS (again, fine, bacause 1 QUADS can be drawn as 2 TRIANGLES_FAN), and it contains some color info and no secondary color, no fog: all this is fine regarding your drawing command. (and the next=0x0 means there is no other renderlist to follow, and this is fine with the simple command block to draw).

[kas1e]

after IOGLES2->aglMakeCurrent(ogles_context); can you make a call to glViewport, like with glViewport(0, 640, 480, 0);

Tried : visually make no differences , same as without.

[ptitSeb]

Mmmm, I must have an issue with default transformation matrix value then.

I'll try to duplicate your simple test using SDL and see if I can reproduce the issue.

[kas1e]

Tried GL_TRIANGLES , also didn't works.

Intersting.. But glClearColor(0.4f, 0.3f, 0.3f, 255.0f); and glClear(GL_COLOR_BUFFER_BIT); works.. , Maybe those functiosn which didn't emulates at all, and just "copy as it" to ogles2 ? (as ogles2 have those functions).

I mean it can be that no function works which are emulated, and those which present in gles2 only works.. What kind of simple test we can do as well by gl calls ?

[ptitSeb]

Use a function that isn't part of gles2? like glBitmap ?

[ptitSeb]

try something like

glRasterPos2f(10, 240);
static char block[] = {0xff, 0xff, 0xff, 0xff};
glColor4f(1.0f, 1.0f, 1.0f, 1.0f);
glBitmap(8, 4, 0, 0, 0, 0, block);

that should put a white rectangle on left/middle of the window.

[ptitSeb]

Ooops, I have the glViewport command wrong. it should be glViewport(0, 0, 800, 480);

(I don't reproduce uour issue on my side, but the block with glBitmap doesn't show up on my side, so don't bother with that for now)

[ptitSeb]

Simply remove the glRasterpos2f command, and the white rectangle should showup in the lower left corner of the window.

[ptitSeb]

what can be also interesting is the uncomment the #define debug in src/gl/uniform.c to see if the matrix uniform is correct (it should be an identity matrix).

[ptitSeb]

Also, when you have time, with commit a479e1e0cd60f751d33699442aa059a8661fc32a I have added some glstate creation/removal when aglContext are created / destroyed. If you can check that agl.c build, and that calling the agl function directly from gl4es and not from OGLES2 library also work :)

[kas1e]

Simply remove the glRasterpos2f command, and the white rectangle should showup in the lower left corner of the window.

Tried with, without, both tests also with and without glViewPort : no draws. glClearColor(0.4f, 0.3f, 0.3f, 255.0f); and glClear(GL_COLOR_BUFFER_BIT); works, but others nope.

Then tested original test-case (that with QUADS), with debug from src/gl/uniform.c, that what i have: http://kas1e.mikendezign.com/aos4/gl4es/log_with_uniforms.txt

Now will try a479e1e commit