It should be probably something else than "ES" variant to properly parse the GL version string which differs in normal OpenGL and OpenGLES. In GL4ES case you probably want to choose "normal" OpenGL somehow (is it via configure?).
@Raziel GL4ES mean pure GL replacement so when you build anything with it means you should choose pure opengl. if you want OpenGL-ES then you need to use pure ogles2 directly without gl4es
I don't understand...is gl4es different to ogles2?
Does that mean that even if i use the GL4ES wrapper, i cannot use it with an app that assumes ogles2?
That would lock ScummVM out from using the GL4ES wrapper? otoh i wouldn't have to waste any more time trying to make it compile and concentrate on SDL1/2 and OpenGL.
@Raziel GL4ES mean to be pure GL replacement, not GL ES replacement or analog. It's just the same GL 2.x. For scummvm in this regards it mean that instead of minigl you use GL4ES. It's just on our side GL4ES works over OGLES2, but this is not OGLES2 per se.
If scummvm wants to build with GL, you choose minigl or gl4es. IF scummvm wants to be built with ogles2, then you use OGLES2 directly.
g++ -athread=native -Wl,--export-dynamic -L/sdk/local/newlib/lib -U__STRICT_ANSI__ -W -Wno-unused-parameter -Wno-empty-body
-fno-operator-names -std=c++11 -gstabs -fvar-tracking-assignments -pedantic -Wno-long-long -Wno-format ./scummvm-conf.cpp -o
./scummvm-conf -L/SDK/local/newlib/lib -lSDL2 -I/SDK/local/newlib/include/SDL2 -D_REENTRANT
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_GetProcAddress':
SDL_os4gl4es.c:(.text+0x34): undefined reference to `aglGetProcAddress'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_CreateContext':
SDL_os4gl4es.c:(.text+0xec): undefined reference to `aglDestroyContext'
SDL_os4gl4es.c:(.text+0x178): undefined reference to `aglCreateContext2'
SDL_os4gl4es.c:(.text+0x18c): undefined reference to `aglMakeCurrent'
SDL_os4gl4es.c:(.text+0x198): undefined reference to `glClear'
SDL_os4gl4es.c:(.text+0x1b0): undefined reference to `glViewport'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_DeleteContext':
SDL_os4gl4es.c:(.text+0x270): undefined reference to `aglDestroyContext'
SDL_os4gl4es.c:(.text+0x2c8): undefined reference to `aglDestroyContext'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_MakeCurrent':
SDL_os4gl4es.c:(.text+0x32c): undefined reference to `aglMakeCurrent'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_SwapWindow':
SDL_os4gl4es.c:(.text+0x3b4): undefined reference to `glFinish'
SDL_os4gl4es.c:(.text+0x3d8): undefined reference to `aglSwapBuffers'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_UpdateWindowPointer':
SDL_os4gl4es.c:(.text+0x43c): undefined reference to `aglSetParams2'
return code: 1
What am i missing? I'm pretty sure i have everything installed.
EDIT: What about libGLUT.a? Do i need to remove/rename that too?
Please bear with me as i think i may have still an error somewhere or a misunderstanding.
You wrote in your readme: Quote:
If you want to use SDL1/2, then there nothing that need to be changed, only compiling lines changes from -lSDL -lGL -lGLU , to -lSDL_gl4es -lglu_gl4es -lgl4es , or to -lSDL2_gl4es if SDL2 in use.
Does that mean that, if i want to compile an SDL2 app i *only* need to change the linker line to use -lSDL2_gl4es and it will pick up the other needed linker libs automatically (-lglu_gl4es, -lgl4es)? Or do i still need to change all the linker libs to -lSDL2_gl4es, -lglu_gl4es, -lgl4es?
Another thing is with renaming. You wrote that Quote:
One may ask, why to remove MiniGL includes, and why not put GL4ES includes to some directory like GL4ES instead of GL (so to not touch MiniGL ones): yes, you can do that. Just when you will later work with GL4ES, then everywhere and every time you will be in need to change include of OpenGL includes from GL to GL4ES directory. And when sometime in your sources you will forget or miss to do so, then you will have name conflicts and clashes. But you can choose the way you want, of course. I just find it easier to have it in GL.
Does that *ONLY* comply to the GL directory? Or is it meant to also work when i rename all of the gl4es linker libs?
Right now i use a script that takes care of all the renaming (and renaming back) automatically when i want to compile a gl4es project (but as you can see above, it doesn't work)
/*
Prepare the original libraries and header files (only SDL2 for now).
*/
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2.a as SDK:local/newlib/lib/libSDL2.a_MGL'
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2.so as SDK:local/newlib/lib/libSDL2.so_MGL'
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libGLU.a as SDK:local/newlib/lib/libGLU.a_MGL'
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libGL.a as SDK:local/newlib/lib/libGL.a_MGL'
ADDRESS COMMAND 'rename SDK:local/common/include/GL as SDK:local/common/include/GL_MGL'
/*
warning: libSDL2-2.0.so, needed by /SDK/local/newlib/lib/libSDL2_net.so
Rename .so for all possibilityst, so it will use .a instead.
*/
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2-2.0.so as SDK:local/newlib/lib/libSDL2-2.0.so_MGL'
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2_net.so as SDK:local/newlib/lib/libSDL2_net.so_MGL'
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2_net-2.0.so.0 as SDK:local/newlib/lib/libSDL2_net-2.0.so.0_MGL'
/*
Prepare OGLES2 specific libraries.
*/
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2_gl4es.a as SDK:local/newlib/lib/libSDL2.a'
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libGLU_gl4es.a as SDK:local/newlib/lib/libGLU.a'
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libgl4es.a as SDK:local/newlib/lib/libGL.a'
ADDRESS COMMAND 'rename SDK:local/common/include/GL4ES as SDK:local/common/include/GL'
I don't want to touch the source for changes, since everytime it changes i will have to change the linker line back, so i'd rather go with renaming (if that is even possible)
Does that mean that, if i want to compile an SDL2 app i *only* need to change the linker line to use -lSDL2_gl4es and it will pick up the other needed linker libs automatically (-lglu_gl4es, -lgl4es)? Or do i still need to change all the linker libs to -lSDL2_gl4es, -lglu_gl4es, -lgl4es?
No, no automatically you need to change all libs.
Quote:
Does that *ONLY* comply to the GL directory? Or is it meant to also work when i rename all of the gl4es linker libs?
Yes only for GL directory, SDL2 includes keeping the same
Slowly getting back my time to test and play around.
If i have the GL4ES SDK correctly installed i should be able to do a simple Quote:
gmake -f makefile
with the included examples and they should compile, right?
Because i get an error there too, which leads me to believe the SDK is incorrectly installed.
ppc-amigaos-g++ -athread=native -Wall example01.cpp -o example01 -lSDL2_gl4es -lgl4es -lglu_gl4es -lpthread
/T/ccC0wWkJ.o: In function `glBegin':
example01.cpp:(.text+0x1a): undefined reference to `mini_CurrentContext'
example01.cpp:(.text+0x1e): undefined reference to `mini_CurrentContext'
example01.cpp:(.text+0x26): undefined reference to `mini_CurrentContext'
example01.cpp:(.text+0x2a): undefined reference to `mini_CurrentContext'
/T/ccC0wWkJ.o: In function `glClear':
example01.cpp:(.text+0x72): undefined reference to `mini_CurrentContext'
/T/ccC0wWkJ.o:example01.cpp:(.text+0x76): more undefined references to `mini_CurrentContext' follow
gmake: *** [all] Error 1
I've had a *little* success today...but only by jumping through many hoops (seems it's too big of a hassle to automate it, but manually changing it all the time is also too much work...for me)
Quote:
LIBGL: Initialising gl4es LIBGL: v1.1.5 built on Apr 17 2021 23:02:30 LIBGL: Using GLES 2.0 backend LIBGL: Using Warp3DNova.library v1 revision 85 LIBGL: Using OGLES2.library v3 revision 1 LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Targeting OpenGL 2.1 LIBGL: NPOT texture handled in hardware LIBGL: Not trying to batch small subsequent glDrawXXXX LIBGL: try to use VBO LIBGL: Force texture for Attachment color0 on FBO LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done LIBGL: Current folder is:Development:Porting/ScummVM/static LIBGL: Shuting down
That seems to indicate ogles2 is used, right?
Who is responsible for the above ogles2 log code?
Because the typos in there are pretty awkward Quote:
LIBGL: OGLES2 Library and Interface opened successfully
@Raziel "undefined reference to `mini_CurrentContext" means you build an app with minigl includes, instead of gl4es ones. More precisely it means that your GL directory somewhere in SDK (and maybe in few places?) contains minigl includes instead of gl4es ones. Easy way to find out : try to find in whole SDK dir all "GL" dirs, to be sure there is only one place (and if not, delete it everywhere). And then, rename it to GL_MGL, create an empty GL directory, and put gl4es includes instead.
Quote:
That seems to indicate ogles2 is used, right? Who is responsible for the above ogles2 log code?
Yea, there gl4es (all with LIBGL: at the beginning coming from gl4es) says to use that ogles2 and warp3dnova were opened fine, etc, etc. So it's output from gl4es.
Quote:
Because the typos in there are pretty awkward
Not sure what kind of typos you mean as for me seems all 3 quotes look correct.
Does the pure OpenGL we have make use of the "enhanced" gfx memory, *if* it is available to the system through the enhancer gfx driver?
Reson for asking is that i compiled a OpenGL app explicitely without gl4es and i still see the "enhanced" gfx memory being used.
I know that gl4es is NOT in use because a) there is no indication in the debug console (no LIBGL, only OpenGL) b) i have the gl4es link libraries renamed and even if they were picked up it shouldn't be available due to a) c) I never really looked at the docky, that shows the "enhanced" gfx memory usage, before today, so i could have easily missed the fact that OpenGL does. d) *IF* i compile the project explicitely with gl4es, i get shader compile errors everytime i run it, so, again, i doubt it's really used.
Does the pure OpenGL we have to make use of the "enhanced" gfx memory, *if* it is available to the system through the enhancer gfx driver?
Yes, a very good example of old opengl being used too (i mean minigl), is BSzili's port of Jedi, which works with enhanced gfx driver on maximum details and eats up about 1 GB of video memory.
But it is used only for uploading GFX data to video memory. In real life, it means uploading of game/app's textures. So if the game has lots of textures, and wants to load them to the video memory, then enhanced drivers there help of course.
glSnoop. But maybe this doesn't helps you much here as the output only contains the translated GLES2/W3DN calls. For additional GL4ES logging/options see gl4es/SDK/Documentation/GL4ES/USAGE.md
LIBGL_DBGSHADERCONV LIBGL_LOGSHADERERROR
you can set them in CLI like: setenv LIBGL_LOGSHADERERROR 1
I knew about the envvars, but i somehow missed the DGBSHADERCONV one.
Have it on now...does anyone can read anything out of the below? Maybe a reason why i don't get a picture?
LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Apr 17 2021 23:02:30
LIBGL: stacktrace will be printed on crash
LIBGL: Using GLES 2.0 backend
LIBGL: Using Warp3DNova.library v1 revision 86
LIBGL: Using OGLES2.library v3 revision 1
LIBGL: OGLES2 Library and Interface open successfuly
LIBGL: Overide version string with "2.1" (should be in the form of "1.x")
LIBGL: Targeting OpenGL 2.1
LIBGL: NPOT texture handled in hardware
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL: Log to the console Error compiling shaders
Log to the console all shaders before and after conversion: Before After Vertex Fragment
LIBGL: Current folder is:Development:Porting/ScummVM/test
LIBGL: Hardware test on current Context...
LIBGL: Hardware Full NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Substract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer detected
LIBGL: Extension GL_OES_element_index_uint detected and used
LIBGL: Extension GL_OES_packed_depth_stencil detected and used
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_texture_float detected and used
LIBGL: Extension GL_AOS4_texture_format_RGB332 detected
LIBGL: Extension GL_AOS4_texture_format_RGB332REV detected
LIBGL: Extension GL_AOS4_texture_format_RGBA1555REV detected and used
LIBGL: Extension GL_AOS4_texture_format_RGBA8888 detected and used
LIBGL: Extension GL_AOS4_texture_format_RGBA8888REV detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Extension GL_EXT_frag_depth detected and used
LIBGL: Max vertex attrib: 16
LIBGL: Max texture size: 16384
LIBGL: Max Varying Vector: 32
LIBGL: Texture Units: 16/16 (hardware: 32), Max lights: 8, Max planes: 6
LIBGL: Extension GL_EXT_texture_filter_anisotropic detected and used
LIBGL: Max Anisotropic filtering: 16
LIBGL: Max Color Attachments: 1 / Draw buffers: 1
LIBGL: Hardware vendor is A-EON Technology Ltd. Written by Daniel 'Daytona675x' Müßener @ GoldenCode.eu
LIBGL: GLSL 300 es supported
LIBGL: GLSL 310 es supported and used
Shader source#version 310
attribute vec4 position;
attribute vec2 texCoordIn;
attribute vec4 blendColorIn;