int nextIdx = min(prevIdx+1, 3); 'min' : no matching overloaded function found '=' : cannot convert from 'const mediump float' to 'highp int'
I found lately about 30-40 shaders which fail on our setups as well, with the same "min': no matching overloaded function found, and throw them at Daniel in the hope it only our setups bring this, but seems iMac/safari WebGL guilty for this error too, just in another shader. Or maybe it will fail the same on our setups too, just currently to make it compiles it ask for 2 missing instructions, and if check on instructions come first, then it can explain all.
Can you also check those ones (which bring us that 'min' errors on our setups):
Did they all will fail on iMac/safari the same as for us ?
I tried to find what is common between them, and find out that they all have some re-define of min(iFrame,0). Like:
Quote:
#define ZERO min(iFrame,0)
or
Quote:
#define motionBlurSteps 10 + min(0,iFrame)
or
Quote:
#define VAR_ZERO min (iFrame, 0)
Not sure though if it that redefines are the culprit.
@Daniel Btw, seeing log output from iMac/Safari where they print guilty line before error: can we do the same? Or we better to print just line number by opStore/etc stuff ?
// find the two closest points 217 vec3[2] closestParmDistIndex = vec3[2](vec3(0, 9e9, 0), vec3(0, 9e9, 0)); 'first-class array' : not supported '[]' : array constructor supported in GLSL ES 3.00 and above only '=' : array / non-array mismatch '=' : cannot convert from 'const array[2] of 3-component vector of float' to 'highp 3-component vector of float' 218 float currentParm = 0.0; 219 for (int i = Z ; i < SEGMENTS ; i++) { 'min' : no matching overloaded function found '=' : cannot convert from 'const mediump float' to 'highp int' 220 vec3 current = path(currentParm); 221 vec3 currentD = p - current; 222 float currentDist = dot(currentD, currentD); 223 if (currentDist < closestParmDistIndex[0].y) { 'y' : field selection requires structure or vector on left hand side 224 closestParmDistIndex[1] = closestParmDistIndex[0]; 225 closestParmDistIndex[0] = vec3(currentParm,currentDist,float(i)); '=' : dimension mismatch 'assign' : cannot convert from 'highp 3-component vector of float' to 'highp float' 226 } else if (currentDist < closestParmDistIndex[1].y) { 'y' : field selection requires structure or vector on left hand side 227 closestParmDistIndex[1] = vec3(currentParm,currentDist,float(i)); '=' : dimension mismatch 'assign' : cannot convert from 'highp 3-component vector of float' to 'highp float' 228 } 229 currentParm -= 0.17 / length(pathd(currentParm)) * paths(currentParm); 230 } 231
232 float dOrg = 8.0; 233 float dShe = 8.0; 234
235 albedo = COLOR_SHELL; 236
237 for (int i = Z; i < 2 ; i++) { 'min' : no matching overloaded function found '=' : cannot convert from 'const mediump float' to 'highp int' 238 float centerParm = closestParmDistIndex[i].x; 'x' : field selection requires structure or vector on left hand side 239 int centerIndex = int(closestParmDistIndex[i].z); 'z' : field selection requires structure or vector on left hand side
303 for(int i=0; i < min(0,iFrame)+6; i++) 'min' : no matching overloaded function found '+' : wrong operand types - no operation '+' exists that takes a left-hand operand of type 'const mediump float' and a right operand of type 'const int' (or there is no acceptable conversion) '<' : wrong operand types - no operation '<' exists that takes a left-hand operand of type 'highp int' and a right operand of type 'const mediump float' (or there is no acceptable conversion)
Perhaps is it possible to add some kinda "include" to the shaders : a text file containing all (Nova) missing fonctions like min(), noise(), etc.. defined as macros This "include" then just need to be concatenated with the shader macro.txt + shader.frag = tmp.frag Then compile/use tmp.frag
With the current Shaderjoy iFrame is float, so you would need to convert all 0 to 0.0 and so on. But the next Shaderjoy version uses integer iFrame so these problems will go away.
I have noticed that when creating the FBOs and then using them as textures, they appear upside down if uv coordinates are generated using gl_FragCoord (gl_FragCoord / resolution.xy).
Is this supposed to happen? It kind of feels unlogical considering that both texture coordinates and gl_FragCoord should have origin at the bottom left corner (after Nova 1.65 anyway?).
@Capehill Most likely you got confused with your UVs somewhere. It's a very common mistake when it comes to FBOs being used as textures. Although I have to admit that I'm not immune to such confusion and to be honest: the primary reason why I think that you and not I got confused here is that IIRC Entwickler-X used FBO textures for cross-platform projects already and I heard no complains In short: yes, usually you'd use flipped Vs for FBO-textures (where the first pixel is bottom-left) compared to lets-call-it file-textures (where the first texel is usually top-left in memory).
Therefore: please doublecheck your code (if possible run the critical stuff on a non-Amiga machine). If you still think that there's an issue then please upload test-code / exe to my FTP.
Right, the Y flipping of file-textures is the usual business and this is configurable per-channel and working as far as I can see.
But the FBOs...texture coordinates are always generated by using gl_FragCoord (application is passing only vertex coordinates) and my unproven hypothesis is that something might be wrong here.
If a fragment is written at the (0,0) coordinate when generating FBO, am I expected to sample the same value with (0,0) texture coordinate?
I cannot see the Shadertoy iOS app doing any extra flipping (they flip only the file texture) but then again, the objective-C is not on my fluent list.
But I keep checking and see if some smaller example can be made. I could try to read back those FBOs and check pixels values or something.
Just finalized OpenGL ES 2 version 3.1 for Warp3D Nova / AmigaOS4. It's available on my FTP for testers and A-Eon devs, as usual. A rather small update this time: - support for the following additional texture data types: GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_BYTE_3_3_2, GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_INT_10_10_10_2, GL_UNSIGNED_INT_2_10_10_10_REV. Those are not defined for the OpenGL ES 2 standard, they are extensions of our implementation. GL_UNSIGNED_SHORT_1_5_5_5_REV has been added to work around a very high texture conversion performance hit in certain games/libs (like 6 seconds instead of less than 1 to load and prepare a texture). The others have been added because it was a 10 minutes thingy anyway, Nova natively supports those formats. - consequently added GL_OES_vertex_type_10_10_10_2 and GL_EXT_texture_type_2_10_10_10_REV to the extensions string. - added support for the texture data types GL_UNSIGNED_INT_8_8_8_8 and GL_UNSIGNED_INT_8_8_8_8_REV. On our big-endian machines, GL_UNSIGNED_INT_8_8_8_8 is actually equivalent to GL_UNSIGNED_BYTE, whereas GL_UNSIGNED_INT_8_8_8_8_REV is like GL_UNSIGNED_BYTE with bytes swapped to the little-endian order. - unfortunately, there are no existing extension strings for all those formats. May well be that our ogles2.lib is the world's only OpenGL ES 2.x implementation that supports all those texture data types at all 😉 Therefore I had to come up with our own extension strings so that client applications and libs like gl4es can actually benefit from those newly supported data types: GL_AOS4_texture_format_RGB332, GL_AOS4_texture_format_RGB332REV, GL_AOS4_texture_format_RGBA1555REV, GL_AOS4_texture_format_RGBA8888, and GL_AOS4_texture_format_RGBA8888REV. - !don't forget to download the new include-folder too! - version set to 3.1 (18.1.2021) Thanks to Kasie Kasovich for inspiring me to do this stuff and for testing it! Cheers, Daytona675x
Now,
let's hope Mattew will not forget to include exactly this new 3.1 version to the upcoming Enhancer, as he always does
@Mattew You will not forget to include ogles3.1 to Enhancer as you do all the time, right ?:)
@All On Ogles2 we didn't have gl_VertexID(), so have anyone any idea how to rewrite that shader, so it will not have gl_VertexID() but still, will works as expected?
@kas1e In general: you cannot really mimic gl_VertexID unless you manually setup an extra vertex attribute and fill it with your own IDs.
Other than that you cannot really rewrite that shader here without a gl_VertexID equivalent and expect it to produce something anywhere near the originally desired output. Unfortunately there's no other shader input that seems to be appropriate to derive the missing info.
Now, I got some small test case which loads up shaders, etc (working them or not, not so matter, that just to loads up and links).
So, they compile fine but fail to links on amigaos4. On win32, the same test-case program absolutely and the same shaders => compiles and links(!) fine. Both Glslangvalidator and w3dnshaderinfo test passes fine, so it just something deeper like maybe on the drivers level
All I find out, for now, is if I comment out in the vertex shader that string: "uniform sampler2D Texture;", then it did links fine! Once I uncomment it back, it stops links!
Question is: wtf ?:)
Maybe the issue is that our vertex shaders just didn't support texture uniforms? Or just something else messed up?
Edited by kas1e on 2021/1/23 9:35:04 Edited by kas1e on 2021/1/23 9:36:55 Edited by kas1e on 2021/1/23 9:37:50 Edited by kas1e on 2021/1/23 9:40:40 Edited by kas1e on 2021/1/23 9:41:45 Edited by kas1e on 2021/1/23 9:45:45
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
