some of you already know, i use Urho3D for mobile devices. This mean OpenGL ES, more specific OpenGL ES 2.0. I came from the pure OpenGL ES 3.0 world and i wrote all my shader code for the corresponding shader versions. I am now making everything downwards compatible (Using varyings again, etc…).
At one function i am not sure how to proof if this would work the modulo function. In my GLES 3 shader code (#version 300 es) i was able to call ‘a%b’. I saw this will not work with GLES 2 so i wanted to implement it myself.
int mod(int a, int b)
{
return a - (b * floor(a/b));
}
But there is no ‘floor’ or ‘round’ function as well so i did
int mod(int a, int b)
{
return a - (b * int(a/b));
}
Now i don’t know if this is valid shader code and i cannot test it in a fast way cause it is used in a very complex shader, maybe someone can tell me if this is valid and if not what are the alternatives?
I suppose that GLES2 hardware may not have integer ops.
If you are sure that only small ints are used (<1kk), you could use float division and then floor it. Or just use float mod.
Or maybe you have some hashing stuff and this is impossible?
This is quite offtopic, but have you tried to make GLES 3 context in Urho?
This is quite offtopic, but have you tried to make GLES 3 context in Urho?
I would wish to but i thought the engine is not capable of GLES 3. I will try to enable it via AndroidManifest and will see what happens. Maybe this will work with SDLSurfaceView or not. Do i need to change the version anywhere else as in the manifest?
I think modulo is not the only function i am missing. Can you recommend any good comparison for GLES 2 and 3?
Did change the SDL_GL_CONTEXT_MAJOR_VERSION to as well no success. Sry, i am not that experienced with computer graphics. (One of the reasons i am here using urho3d)
But i thought there is a direct correspondence between the GLES version and the version of the shader language.
The
#version 300 es
is working with my old stringified shader which i load via cpp and used with opengl. So it can work on Android and on this specific device.
I thought there is maybe a site where i can see ‘This feature only gles3 -> not gles2’. E.g.: idk if it is supporter by the actual shader version to use:
void func(in vec4 a, in vec4 b, out vec4 c, out int n)
from OGLGraphics.cpp and rebuild the whole engine? Or can i set it from outside, eg. int the jni cpp callbacks of sdl?
Do you mean that you have some sample GLES application to check things?
So i will try to describe where i come from. I created a mobile application with Android NDK and JNI as my glue between java and cpp code. My first attempt to render output was using a GLSurfaceView which define my egl context in combination with c++ opengl bindings and stringified glsl shader code. To make things more simple and robust i decided to use urho3d.
So i started to port my rendering pipeline to urho3d, which made it necessary to change my GLSurfaceView to a SDLActivity with its own surface view, which inherits from a SurfaceView. The shader code which was working with the first approach seems to be not supported due to the described version issues of the GL Shading Language.
This. Set SDL_GL_CONTEXT_MAJOR_VERSION where it’s set now. Probably, it’s better to set SDL_GL_CONTEXT_PROFILE_MASK too, in the same place. And build Urho, yes.
Okay, i think i will just try changing my code from 3.0 to 1.0 Shading Language. You suggestion with the ‘floor’ function works now, will have to figure out some other issues as well.
It is me again, didn’t want to create an additional thread. My shader code is running now, it only remains one crucial problem.
I have to block interpolation of some variables from my VertexShader to my PixelShader. Normally this would be really easy i would use the qualifier ‘flat’, which prevents the interpolation after rasterization for those values. Any suggestion how to workaround in this lower version of the Shading Language?
There’s no generic way to workaround flat modifier.
It was asked before to add GLES3 support, so I’ll look into this direction. Will try something this weekend. IDK why you weren’t able to create GLES3 context tho.
Towards the end there’s some commits for GLES3, I don’t believe it’s usable as-is looked like he went a little nuclear with it instead of coexisting with GLES2. All-in-all though looked pretty simple … I was going to get to it eventually in wrapping up GS/HS/DS once I was testing on mobile.
Not yet, haven’t made a droid build for like 2 years - dreading it.
You’re right though, just looks like the shader version stuff (pushing the #300) that’s nuke. There’s probably some other GLES ifdefs that need some tweaks, the depth texture stuff being the big one I can think of that might.
I can confirm it is working for me with the mentioned commits, thy you all for your effort :). Hope to see it by default enabled in the engine in the future.