As some of you may know, there was another attempt we discuss before which make OpenGL apps to works on OpenGLES, which is called glshim.
I follow that development on the Pyra's/Pandora's forum, there was a pretty nice long discussion of 36 pages of how it all develops, what it can or don't, what games they port over it, and so on
Seeing from comments on GitHub, you may see that since 2016 development has mostly stopped, and in 2017 there was only one commit.
But it's all about glshim originally. Then, at some point (in 2015 or something), another author made a fork of it, and start to develop it further (at the beginning in parallel with glshim, then probably the author of glshim loses interest and only that fork continues to develop).
And to have 2 wrappers (Regal and GL4ES) is better than having only Regal, and I give it a go as well.
Structure of the project not as good as Regal's one, and it's depends not only on X11 in a few parts but also on EGL. It also uses CMAKE and not pure Make.
So, i just check how it all builds on Linux, and make a pure makefile for os4 which will build necessary objects, only to realize that X11 can be disabled easily (it is already disabled for Android), while EGL is used much. I then write a ticket for, in case to ask for some clarification, and author says:
Quote:
EGL is used at minimum in 3 places (besides the GLES context creation):
1. At init, to create a small pbuffer to get Hardware information support. This part can be skipped with LIBGL_NOTEST=1
2. For eglGetProcAddress to get extension function adresses.
3. for eglSwapBuffers to swap buffers (actually put drawing onscreen).
I then explain to him that we are at amiga and all that necessary stuff, and, he is still in interest to deal with it! Today he made a commit where add initial NOEGL stuff, and what he wrote about:
Quote:
It should be working for you now. Some guidelines:
Compile with NOEGL (the NOX11 will be set anyway). Use with Export LIBGL_ES=2 (or define a DEFAULT_ES=2 at compile time). You will need to create the GLES context yourself There is no Hardware checking for capability, so only basic functions will be used You need to SwapBuffers yourself. To stay on the safe side (because gl4es has many optimizations and may cache/batch drawing calls), it's better to call either glFlush() or glFinish() before the SwapBuffers.
So, all of this is even better for checks: As i, of course, need and want to create GLES context myself, as well as i for myself, want to do aglSwapBuffers().
Through, at moment, not everything handled as needing it with NOEGL, as well as there are other code-compile bugs (strange!), but he seems still to work on, and we can expect something soon!
Some info: we are able to build all objects of main gl4es code, make a link library from it, and even try to link it against test code : have some bunch of undefs which need to be fixed, but proably soon.
Also, he add amigaos4 target as well, so it's all will be in repo.
@Capehill Can you also point out plz how later it used. I.e. you open somewhere ogles2.library, and when you call AmiGetGLESProc ?
Maybe you can have a look at that loader.c file, and have idea how we can integrate it all there.
That what author answer me about how it works with dlsym() in gl4es:
Quote:
For dlopen/dlsym. dlopen open an handle, and "load" a dynamic library. Then, with dlsym, you get address of a function based on it's name. gl4es works like this: for example, if your program use glDrawElements(...) Because you are linked (staticaly or dynamcaly) to gl4es, you call the glDrawElements(...) from gl4es, that is an alias for gl4es_glDrawElements(...) This fonction will do some specific stuff, depending on the parameters used (for example, you can call with GL_QUADS that is not supported on OGLES2, but is supported on full OpenGL, and gl4es will handle that as well). At some point, gl4es will call the "real" glDrawElements(...) from OGLES2 driver, so it will get the function pointer using dlsym(gles, "glDrawElements") and call that function, so the GLES2 driver can draw the things. All call in gl4es are wrapped in a similar way. You never call function from the GLES2 driver directly. It gl4es that does it. And gl4es will make some optimisation, cache things, and limits the number of calls to GLES2 driver to try get more speed...
@Capehill Ok.. then it mean that ogles2.library should be opened from gl4es, then. Damn, was in hope to avoid it , just to make it same as regal (i.e. no opening of any libraries in, but doing all from users's code)
Now i am abit out of ideas, that what author say:
Quote:
I'm not confident this will work. You will have name collision between the ogles2 function name and gl4es funciton name, that will be the same. That's why I use dlopen on gl4es. the glXXX name of gl4es are the one to be used by the program, and the glXXX name of ogles2 are the one used only by gl4es. But those are the same name, so if you link with both ogles2 and gl4es, how to know wich one to use? Or maybe I haven't understood how that OpenLib works...
I must insist, gl4es is not working like Regal. Regal create some new function, with a different name, where gl4es create full OpenGL functions. I have not created any "mangling" mecanism for gl4es. gl4es is an OpenGL library: you put it in your system and you use OpenGL program without recompiling.
Now, can I just use that AmigaGetGLESProc(...) function from SDL? will it give the ogles2 function pointer without masking the gl4es function?
Use the interface to the ogles2.library directly rather than any stub library, that you might use for compiling simplicity.
eg MiniGL programs are usually linkied against libminigl.a or .so which contains stub functions that call the library calls. I'm assuming that ogles2.librray will work similarly.
olgesSomeFunc() will not then clash with IOgles->olglesSomefunc()
The library *could* be opened in a constructor, it need not be opend in the link lib ne it static or sobj.
The Interface could be extern to the new library and provided in the users code.
21483 frames drawn, for a total of 8169.000000 milliseconds Took approximately 0.380254 milliseconds per frame Avarage FPS: 2629.820051 Took approximately 0.474701 milliseconds per frame (with swap) Avarage FPS (with swap): 2106.589527
And as i post in Regal's topic:
MiniGL:
Quote:
27488 frames drawn, for a total of 10097.000000 milliseconds Took approximately 0.367324 milliseconds per frame Avarage FPS: 2722.392790 Took approximately 0.470714 milliseconds per frame (with swap) Avarage FPS (with swap): 2124.430018
Regal:
Quote:
32814 frames drawn, for a total of 16080.000000 milliseconds Took approximately 0.490035 milliseconds per frame Avarage FPS: 2040.671642 Took approximately 0.587737 milliseconds per frame (with swap) Avarage FPS (with swap): 1701.441460
As you see, the result is much better than with Regal. Its on pair with MiniGL, which , do not be confused, very good result for such a simple test case because of reassons Daniel wrote in Regal's topic (slow first frame, too simple code, so not show potential of overload and so on).
@Daniel
Can you plz run that test on your Sam, so we will see how it in compare with MiniGL reloaded. Probably on the same level, or even better a little ?
ogles2.library and interface opened in the gl4es.a itself.
So, once i try to run it as it, it freeze amigaos. But not all the time on the same place. Sometime, it go till initialising gl4es, and then crash (so, even didn't touch a part of code where we do amiga stuff at all), sometime go futher and then crash right after i open window.
Of course for sake of tests tried to use bigger stack size too.
Then, once i start remove parts of code (different ones), it works. But not the same parts of code.
Its like the more code i have (does not matter what functions, etc, just more code), then it crashes.
For example, i may comment some parts in the main() : don't crash. Or may comment some parts in draw(), while keep what was commented in main : don't crash.
I.e. commenting out different parts of code, to make code of binary smaller (probably, i am not sure), make it not crash.
Its like some overbound/overflow/dunno what somewhere. But something general.
Have anyone any idea to where look at ? I mean that kind of symptoms can cause what ?
It also seems, that putting Delay() all over place, can make difference for point when crash happens. And that remind me some racecondition issues .. Maybe still that we open library and interface in the libgl4es.a itself, and in programm use just as it OGLES2, make problems ?
@kas1e Now, this looks even more promising as Regal Checked your binary on my sam460:
Quote:
LIBGL: Initialising gl4es LIBGL: v1.0.5 built on Feb 17 2018 23:41:49 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:RAM Disk: 20457 frames drawn, for a total of 11217.000000 milliseconds Took approximately 0.548321 milliseconds per frame Avarage FPS: 1823.749666 Took approximately 0.652686 milliseconds per frame (with swap) Avarage FPS (with swap): 1532.130018
So on my side all the msec results for this test are (smaller = better): Quote:
So with this test it's a bit faster than my current MGLReloaded and, no surprise, slower as original MGL.
Didn't compare Regal vs gl4es, but if the feature-set is more or less identical I would concentrate on gl4es if I were you (also because the author apparently is both active and helpful)
Quote:
So, once i try to run it as it, it freeze amigaos. But not all the time on the same place.
From a quick look, you only defined 6 normals for 8 vertices.
@Daytona675x And the size of binary lots smaller than regal one. Through in terms of compatibility regal should be better, but that to be checked. Gl4ES mostly for opengl1.5 and 2.0 for moment , but author optimize and fine tune it very well (at least better than Regal). He even say that arrays in shaders always not so fast, and he get rid where it possible of them in the generated shaders.
As for crash: sure, gl-code-wise it can be wrong, but it works copy of minigl example, and even if call some stuff which make no sense to call, it shouldn't crash so heavy in different places (most of time right after open of window).
As for crash: sure, gl-code-wise it can be wrong, but it works copy of minigl example,
The normal array has to be larger and filled with correct normals, otherwise you are at least doing illegal memory reads with potentially trashed data. And you know what trashed data for a normal likely is? Most likely not a normal anymore And a normal which is not a normal may easily provoke crashs on code which asumes that it is a normal. Please fix the normal-array and try again.
And you know what trashed data for a normal likely is? Most likely not a normal anymore And a normal which is not a normal may easily provoke crashs on code which asumes that it is a normal.
Quote:
Please fix the normal-array and try again.
Funny thing is that "random" crash wasn't random. Its just i run test case from shell, and window which opened put shell window behind the gles2 window, and while aglSwapBuffers() not done, there is copy of the screen in the window. So, i watch on that window thinking that there is just few printfs, while they go futher in the shell behind the window, which make me think nothing happens :)
It still strangely crashes: if i put bunch of printfs in Drawbox() before and after every gl call, then, its make 3 loops, and then crashes. But will firstly try to fix normales.
Probably it didn't crash in Regal before, because for that example Regal create shaders with arrays (and so nothing draws, but didn't crash), while, GL4ES create shaders without arrays -> code tryin to executes -> crash.
Through that only suggestion until didn't fix normales, maybe it bug in gl4es's glMatrixMode (as it works in MiniGL after all..). Will see now
@Daniel Btw, just to be sure its not in spam box : did you recieve reports on mail about glGetActiveUniform(...) and glGetActiveAttrib(...) ?
Edited by kas1e on 2018/2/18 10:18:52 Edited by kas1e on 2018/2/18 10:20:09
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
