@Sonic Those "std::xxxx" errors are cosmetic, just fix once they arrive.
It was fixed in latest newlib , yes, but it also mean new adtools build around it, as well as no one know when new newlib will be out. Waiting for those simple cosmetic-error for another few years of course no-go.
I for myself in all ports just dealing with it manually, and that all.
The game Giddy 3 (old version) shows some black background flickering when playing using MiniGL4GL4ES.
Since the version available on OS4Depot is quite old i thought lets compile the more recent version of Giddy 3 and link it directly against GL4ES. Giddy 3 uses native AmigaOS4 code in order to draw to the screen (P96+MiniGL). I adjusted the OS4 render paths in order use OpenGL directly (like linux/pandora versions) so no more calls to P96+MiniGL.
The funny but bad thing: The new Giddy 3 build using GL4ES directly shows excactly the same rendering issues regarding black background flickering. I tried out almost all GL4ES environment variables but no luck so far.
And here is how it looks:
Maybe this is something where GL4ES can be improved. If you need the sources of new Giddy 3 or anything else let me know.
Those old and very old games, which use GLBegin/GLEnd route most of time will be of the same speed over gl4es and minigl (and even can sometime be slower over gl4es). Gl4es is mostly for new stuff, written in having in mind all the VBO and stuff.
As for issues with minigl4gl4es and directly gl4es : minigl4gl4es uses gl4es fully, so no surprise the same bug arise everywhere. And as you can reproduce it easy on direct usage of gl4es, i assume you need to create bug-report to ptitseb about , there : https://github.com/ptitSeb/gl4es/issues
He very helpfull, and if you will bring to him links, sources (which can be compiled on any platform) and point out on what wrong , he surely can check and fix it (as he do most of the times). Or at least he may bring some idea about what can be wrong, etc.
Ok thank you. I'll file a bug report at GitHub later.
Quote:
As for issues with minigl4gl4es and directly gl4es : minigl4gl4es uses gl4es fully, so no surprise the same bug arise everywhere.
In general yes of course, but MiniGL4GL4ES has been build over 15 months ago and uses a GL4ES version from that time. Recently released GL4ES Library has vastly improved GL compatibility. TriggerRally for example, from zero to (almost) hero
I forgot how i did it and now i'm getting a lot of these...any hints?
/SDK/local/newlib/lib/libGL.a(arbconverter.c.obj): In function `gl4es_convertARB':
arbconverter.c:(.text+0x0): multiple definition of `gl4es_convertARB'
/SDK/local/newlib/lib/libGL.a(arbconverter.c.obj):arbconverter.c:(.text+0x0): first defined here
/SDK/local/newlib/lib/libGL.a(arbgenerator.c.obj): In function `generateVariablePre':
arbgenerator.c:(.text+0x0): multiple definition of `generateVariablePre'
/SDK/local/newlib/lib/libGL.a(arbgenerator.c.obj):arbgenerator.c:(.text+0x0): first defined here
/SDK/local/newlib/lib/libGL.a(arbgenerator.c.obj): In function `generateInstruction':
arbgenerator.c:(.text+0x4c0): multiple definition of `generateInstruction'
/SDK/local/newlib/lib/libGL.a(arbgenerator.c.obj):arbgenerator.c:(.text+0x4c0): first defined here
/SDK/local/newlib/lib/libGL.a(arbgenerator.c.obj): In function `generateVariablePst':
arbgenerator.c:(.text+0x57078): multiple definition of `generateVariablePst'
/SDK/local/newlib/lib/libGL.a(arbgenerator.c.obj):arbgenerator.c:(.text+0x57078): first defined here
/SDK/local/newlib/lib/libGL.a(arbhelper.c.obj): In function `resize':
arbhelper.c:(.text+0x0): multiple definition of `resize'
/SDK/local/newlib/lib/libGL.a(arbhelper.c.obj):arbhelper.c:(.text+0x0): first defined here
/SDK/local/newlib/lib/libGL.a(arbhelper.c.obj): In function `initArray':
arbhelper.c:(.text+0x74): multiple definition of `initArray'
/SDK/local/newlib/lib/libGL.a(arbhelper.c.obj):arbhelper.c:(.text+0x74): first defined here
/SDK/local/newlib/lib/libGL.a(arbhelper.c.obj): In function `pushArray':
I did rename sdk:local/common/GL4ES to GL sdk:local/newlib/lib/libgl4es.a to libgl.a sdk:local/newlib/lib/libGLU_gl4es.a to libGLU.a sdk:local/newlib/lib/libSDL2_gl4es.a to libSDL2.a
i suspect something stupendously easy to fix, but i can't get my head around what. Something is missing...
If you use GL4ES, then you of course can't link with libGL.a which is minigl. You should link with LIBgl4es.a or how it is called in the SDK of gl4es.
If you use SDL2, then you also should use libSDL2_gl4es.a , and link with it (and not with pure libSDL2.a).
Also to resolve all possible problems, just delete everything and start from scratch: rename your minigl GL headers from SDK on something like MGL_GL, create a new GL directory in the same place and put gl4es includes from.
Then, compile everything from scratch. IF all ok, then only linking left and there you should use all the same lbs as before but those which come with gl4es SDK should be replaced too (libSDL2_gl4es, libGLU if need it, etc).
I tried to cover gl4es SDK installation as much easy as possible in the readme, double-check if you follow 100% it.
All you need is to use the right includes, and right link libraries.
The first "working" one was done static. Since then i switched to shared builds and it seems as if gles4 doesn't like to be mixed with shared libs, so...unfortunately i have to drop it.
Do you think, in the light of the latest shared library fixes, you could provide shared builds as well?
wrt speed...if you read one of my last mails i wrote that i never managed to make cummVM run with OpenGLES2. It errored out with a missing screenmode...so, no
ok then, maybe ogles2 will be integrated into the system/sdk closer in the future, so i can drop all the renaming/library handling and see how that goes
Could you tell me if this output is correct...so far? I know that the shaders break, but that could be because shaders are still disabled by configure (have to still figure out why)
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:Games:ScummVM
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
WARNING: Could not parse GL version '2.1 gl4es wrapper 1.1.5'!
WARNING: GL ERROR: GL_INVALID_VALUE on glCompileShader(handle) (backends/graphics/opengl/shader.cpp:270)!
WARNING: Could not compile shader "attribute vec4 position;
attribute vec2 texCoordIn;
attribute vec4 blendColorIn;
I get a black screen/window with a white rectangle on the top right when running ScummVM. Progress, but it doesn't seem to be there yet.
Also, i *have* to compile a static version, mixing shared and static doesn't work, so any ogles2 release will probably be a cross-compile (if there ever will be one, that is)
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
