On OS4 there should be no exclusion in a sense that you should be able to run both OGLES2 and MiniGL apps at the same time, if you have the necessary drivers. Programmer makes a decision which one (MiniGL or OGLES2) is opened and used.
Its 2 different realisations (different libraries, different fucntions). OpenGLES2 is limited set of OpenGL2. I.e. there is full OpenGL2 and OpenGLES2, its reduced versions of OpenGL2 with less functions, no fixed pipiline, some more legacy removed (for easy work on mobile devices, etc)
On os4 we have 1 realisation of full opengl : minigl. Which is also limited, but not because of standard as opengles2, but just some fucntions not implemnted, and minigl is just opengl 1.5.
Quote:
If one is used the other can't be used?
As 2 different programms at the same time: yes. As one programm which use both: no (as context different).
You can open minigl.library, create context of minigl (opengl) and use opengl functions. Or, you can open ogles2.library, and use its context (which by logic alos opengl context, but different anyway, as different library , etc). Some functions of opengl are the same as in ogles2 (of course, as ogles2 its opengl, just with less fucntions).
Quote:
Or is OpenGLES just an addition to OpenGL and without OpenGL it wouldn't work for itself?
Its 2 differetn realisation of opengl standard. Full opengl are full, and opengles are opengl with less fucntions.
In terms of SDL, you choice from SDL app what one to use.
In the net, you can find sources which use opengl, or opengles, and they will be different. Of course, it possible to write opengl code , which will works "as it" over opengles , but most time it will not, as full opengl will use one or another function which not present in ogles2.
Because of that, we worry about that gl4es : to have full opengl. I.e. again making jumbo mambo, to have full opengl via something else (in our case it is gl4es->ogles2.library->warp3dnova.library).
Of course , if we have in first place just some mesa opengl driver for full opengl, there wasn't needs not for ogles2.library, not for gl4es. But as writing full opengl driver is much harder than ogles2 driver, we have what we have.
The opengles2 implementation is "complete", isn't it? Nothing left out from the "official" opengles2?
Because then it's a matter of supporting it correctly or dig a little deeper as to why it kind of work, but not completely (e.g. wrong colors on moveable objects etc.).
Maybe there are functions (ab)used that we don't have?
EDIT: I have a project where it tries to compile with "-lGLESv2" instead of "-lGLES2"...so what is the correct way? Nevermind...seems i need to use "-logles2" to make it link correctly
Edited by Raziel on 2018/11/11 12:24:55 Edited by Raziel on 2018/11/11 12:27:06 Edited by Raziel on 2018/11/11 13:00:58
Do the opengles2 examples from the Enhancer SDK directory crash on exit for you too?
They run fine, but whenever i close the window, it's nirvana for me, that bad, that i have to unplug the X1000 for 10 seconds to make it come back to life.
The opengles2 implementation is "complete", isn't it? Nothing left out from the "official" opengles2?
As far as i know : yes, it is fully complete, and even some functionality added from opengles3 (a little, but still).
In the Warp3dnova itself missing at moment (taken from Daniel's ogles2.library readme): sample coverage, dithering, compressed textures and render-to-texture, which mean it also missing in ogles2 because of that. I.e all functions of opengles2 standard are in, just when this kind of functionality used, it probabaly return "true" without doing anything. But for example in gl4es (which is real big thing), none of that feature used, so my bet they at moment missing as really unimportant (except probabaly those 2 about textures).
Hans and Daniel know things better about of course, but i think i not mistaken anything there.
Quote:
Because then it's a matter of supporting it correctly or dig a little deeper as to why it kind of work, but not completely (e.g. wrong colors on moveable objects etc.).
I can tell from all my tests with gl4es and bug reports to ogles2 and warp3dnova : that at moment it's all complete enough and all works as should. Some bugs still left in warp3dnova, but Hans works on them.
Quote:
Maybe there are functions (ab)used that we don't have?
In terms of realisation of opengles2 our Daniel's ogles2.library is "full", with even some bits from opengles3 standard.
Quote:
I have a project where it tries to compile with "-lGLESv2" instead of "-lGLES2"...so what is the correct way? Nevermind...seems i need to use "-logles2" to make it link correctly
Yeah, its just matter of naming. I doing tests on all oses where i have opengles2 support, and -lGLESv2 happens to be on win32 for me as well. On os4 we just use -logles2, yep. But name of fucntions, headers, etc, all of course about the same.
Quote:
Could not compile shader box.vertex: ERROR: Code generation failed. Error log: Boolean uniforms aren't supported yet: offset: 24, size: 1, Bool flipY INTERNAL ERROR: OpBranchConditional instruction's source parameters are missing
Can you upload that shader somewhere ?
Usually, when i want to know, if shader works at all, or if it works on our warp3dnova, i do that:
1. I use glslangvalidator (latest version from Daniel), placed there:
So, via that glslangvalidator i check, if shader is working at all (glslanvvalidator check shader for be "normal one" at all, does not matter on what OS and on which drivers). If it compiles fine, then it mean that shader by itself ok.
2. Then i use Warp3DNovaShaderInfo utility which come with warp3dnova sdk, and take the converted shader from glslangvalidator as input for warp3dnovashaderinfo.
Then, if there is no error : then shader also works over warp3dnova. But if there is error, then its bug in the warp3dnova, which need to be reported, and Hans will fix it.
@Raziel I also do not know shader's language, but i tested your one: and glslangvalidator errors on it with errors 'in for stage inputs': no supported for this version or enabled extensions.
I do not know what it all mean, but i can only say from test that its issue in the shader itself, and not related to ogles2.library or warp3dnova.
glslangvalidator its kind of "de facto" tool from the those ones who made standard, and if it didn't works over it, then something wrong in shader.
@Raziel Then why it didn't works over glslangvalidator ? If only it is something very new, and even new glslangvalidator from Daniel are too old for :) But yep, there need Daniel or Hans.
Well, first of all, i don't even know if that is the correct shader (or if it even *IS* a shader), i just found it under the same name in the source, but that doesn't really mean anything
Maybe it's just some kind of handshake code for the real shader?
@Raziel It is for sure shader, and are vertex one (see at end gl_position word). Also structured like usual shader: init stuff at top, then main with gl_position. It just seems something at top can be missing, or our new glslangvalidator too old (code of which also in ogles2.library)
As far as i know : yes, it is fully complete, and even some functionality added from opengles3 (a little, but still).
Not quite. There are a few shader instructions/features missing still, like the uniform booleans that Raziel has hit.
Quote:
In the Warp3dnova itself missing at moment (taken from Daniel's ogles2.library readme): sample coverage, dithering, compressed textures and render-to-texture, which mean it also missing in ogles2 because of that.
Correction, render-to-texture has been in there for ages now (over a year).
@Raziel (& @kas1e) Quote:
That would be starnge as that shader works on dozens of other platforms, just not on AmigaOS4...i highly doubt that it's an issue with the shader.
GLSLangValidator is stricter than most OpenGL implementations. As "validator" and reference compiler, it checks whether the GLSL code is fully GLSL compliant. Most OpenGL implementations relax the rules and are more tolerant of mixing code from different GLSL versions.
The shader you posted uses GLSL v1.40+ features without specifying the GLSL version. That's why GLSLangValidator is giving "not supported in this version" errors. Adding "#version 140" at the top (without the quotes) should be enough to make GLSLangValidator accept it.
That shader isn't the one giving you the "Boolean uniforms aren't supported yet" error message, though. Look for a shader that has "uniform bool" in it.
To workaround the missing uniform bool support, change the uniform bools to integers as kas1e suggested, and then you need to go through the code and cast the variable to a bool.
For example, if you had: uniform bool someBool;
Then you'd go through the code below, replacing someBool with bool(someBool).
Boolean uniforms aren't supported yet because booleans aren't 32-bit, and will need special handling to implement.
>boolean expression expected I already had this error too with a boolean (converted to int) like this if(FlatColor) Colour=CurrentColor; was fixed this way if(FlatColor==1) Colour=CurrentColor;
As kas1e said your shader is not the one that contain Bool flipY Simply use a search tool for files containing flipY in your sources and change it from bool to int
As far as i know : yes, it is fully complete, and even some functionality added from opengles3 (a little, but still).
Not quite. There are a few shader instructions/features missing still, like the uniform booleans that Raziel has hit.
Thank you for the confirmation.
Quote:
That shader isn't the one giving you the "Boolean uniforms aren't supported yet" error message, though. Look for a shader that has "uniform bool" in it.
To workaround the missing uniform bool support, change the uniform bools to integers as kas1e suggested, and then you need to go through the code and cast the variable to a bool.
For example, if you had: uniform bool someBool;
Then you'd go through the code below, replacing someBool with bool(someBool).
I already did go through the code, but with my obvious limited (rather non-existant) coding skills, i was simply exchanging every "bool" i found with "int", which is wrong
I'll try again with your example.
Quote:
Boolean uniforms aren't supported yet because booleans aren't 32-bit, and will need special handling to implement.
Of course i know it's always pretty much impossible to give time frames, but what includes this "special handling" and how long do you think will it take to support them properly?
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
