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;
@Raziel At least you go far enough with gl4es already :)
So, now, when you certainly have running gl4es build as can be seen, you need to be sure you don't have shader-compilation errors.
What you need, is to enable output of not original shaders, but shaders generated by gl4es (internal ones and re-generated from shaders coming with scummvm if there is any). So then you grab then one by one, and firstly by using glslangvalidator port from Daniel (last one from latest warp3dnova releases) compile SPRV files from them (to see, that syntax all correct and so on), and then, after, you use Hans's W3DNShaderInfo (coming with warp3dnova in example/Shaderinfo/). To see if it bring errors.
Yeah, not only is it hard to understand, but it also is so illogical sometimes...
I'll have to put this on hold in the meantime, anyway. There seems to be some missing extensions, which would normally be included if the backend uses GLEW (which we don't).
Have to wait for some PR getting merged and then try again.
Want to resurrect this thread with some interesting info which I know those who are interested in 3D on OS4 (especially on x5000), will be interested in the info above.
So, yesterday I just tested some beta components: the latest kernel and the latest Radeon RX driver. The kernel I tested doesn't mean being multicore, just the usual kernel with some improvements mostly from Thomas, and just the next version of the Radeon RX driver by Hans.
Together kernel and new gfx drivers bring some unbelievable speed up in ports i do via GL4ES (which use Warp3DNova and ogles2.library). MiniGL apps also have some speed up, but not that big as with GL4ES apps.
For example, take the quake3 and 1920x1080 fullscreen / all settings max / usual "timedemo 1/demo four running 3 times" on my X5000:
MiniGL version on RadeonHD SI: ~75 FPS GL4ES version on public components on Radeon RX: ~78 FPS GL4ES version on beta components on Radeon RX: ~133 FPS (!)
Yes, +55FPS!
I retested more games, and there are results:
"Quake3"'s timedemo1/demo four: +55fps "HCraft" vary, from 30 to 50 fps more Worlds: vary, in general from 15-30FPS more SuperTuxKart : +15 FPS more FooBillard++ : +25 FPS more NeverBall : + 100 FPS more NeverPutt : + 150 FPS more Friking Shark: +50 FPS more Irrlicht_demos: Quaketest + 25FPS, shaders tests + 800FPS, meshviwer test + 200 fps, "demo" example + 35 FPS.
In other words, it is just something unbelievable. I find out that speed increase comes from both kernel and Radeon RX drivers. About 30% come from Kernel (probably once Thomas add "dcbz only use half cache lines on X5000") and 70% come from Radeon RX change which is "Reduced overhead of getBMBytesPerRow(). It used to lock and unlock the bitmap, which is rather slow". Not sure that authors expect such a massive change, but that comes as a real unexpected bonus.
To see it all in action, you can watch a video made (as usual with comments and stuff) where I test 7-8 GL4ES game ports, so you can see the figures of FPS and compare if you are in interest.
News feed
OS4 Feedback forum
OS4Depot Feedback 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
Beta tests of 3D graphics on X5000 in november 2011. 1920x1080 full HD