Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
107 user(s) are online (62 user(s) are browsing Forums)

Members: 0
Guests: 107

more...

Headlines

 
  Register To Post  

« 1 ... 29 30 31 (32) 33 34 35 ... 42 »
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Capehill

Yes, sorry about that, here it is:
http://www.amigans.net/modules/xforum ... id=113837#forumpost113837

Do you have the modern theme in place?
And did you try to open it with unarc?

I don't know how you installed scummvm but sometimes "cp" cripples the theme file on copying.

Recopy it from yor source and you should be fine.

I can provide a static build tomorrow.

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Capehill

You've got PM

There are some more odditiies with ogles2.

If glsnoop is in place the start of scummvm is slow enough to see it.
1) the screen that is opened is not black but a mush of pixel lines in different colors, the same goes for the mouse pointer until the screen is fully loaded and both go back to normal.
2) If i return to launcher without closing scummvm (RTL from within a game) then the mouse pointer will be in either of two states.
--- 1 - It will be a box of mushed up gfx garbage or
--- 2 - it will be completely invisible (this is the case for about 75%)

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Just can't stay away


See User information
@Raziel

I have also seen some transient visual issues with ScummVM/OGLES2 version ("first frame broken", "strange mouse pointer"). Could have something to do with texture update.

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Capehill

Thank you for the confirmation...glad it has nothing do with my hardware.

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Just can't stay away


See User information
@Raziel

Added a frame counter print and some delay after SDL_GL_SwapWindow call in ScummVM code. The first frame is mostly pink, with some red and black pixels. The second frame is OK. If I disable either FBO or multitexturing in context.cpp, the first frame becomes black while the second is ok. Need more experimenting and understanding, and maybe some FBO test example. I have never used one, maybe it's time to try.

EDIT: fixed SDL function name


Edited by Capehill on 2019/7/31 18:42:13
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Capehill

Thank you very much

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans

I reduced as much as possible FrickingShark shaders, so they still works fine and over gl4es on Pandora, and just on win32 version without gl4es.

Original shaders in use now are:

Vertex one:

uniform vec3 g_vHeightFogMins;
uniform vec3 g_vHeightFogMaxs;
uniform mat4 CameraModelViewInverse;
varying vec3 g_WorldVertexPos;
varying vec4 g_EyeVertexPos;

// FOG
varying float g_fFogFactor;
// ---

void main (void)
{
    
vec4 LocalVertexPos=gl_Vertex;
    
g_EyeVertexPos=gl_ModelViewMatrix LocalVertexPos;
    
vec4 WorldVertexPos=CameraModelViewInverse g_EyeVertexPos;
    
g_WorldVertexPos=WorldVertexPos.xyz;
    
    
gl_Position ftransform();

// FOG
    
float fFogSize=g_vHeightFogMaxs.y-g_vHeightFogMins.y;
    
float fFogDist=WorldVertexPos.y-g_vHeightFogMins.y;
    
g_fFogFactor=1.0-fFogDist/fFogSize;
// ---
    
    
gl_FrontColor=gl_Color;
    
    
gl_TexCoord[0]=gl_TextureMatrix[0]*gl_MultiTexCoord0;

}


Fragment one:

uniform sampler2D Texture0;

// FOG
varying float g_fFogFactor;
// ---

void main (void
{
  
vec4 texcolor=gl_Color;  
  
texcolor*= texture2D(Texture0gl_TexCoord[0].xy);
// FOG
  
texcolor.rgb=mix(texcolor.rgb,gl_Fog.color.rgb,g_fFogFactor);
// ---

  
gl_FragColor=texcolor;
}


And with those shaders on win32 and on pandora with gl4es we have that:

(press open in new tab for fullscreen):

Resized Image


So all renders correctly, but on amigaos4 it fail like this:

(press open in new tab for fullscreen):

Resized Image

Pathes to textures of course fine and so on (because when shaders disabled, all renders fine from same code).


Also that how those shaders looks like after shaderconv of gl4es regenerate them and send to ogles2, and those ones we can test on our side (thank for glSnoop to take and see them easy!)

Vertex one:

#version 100
precision highp float;
precision highp int;
uniform highp mat4 _gl4es_ModelViewMatrix;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
uniform highp mat4 _gl4es_TextureMatrix[8];
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
attribute highp vec4 _gl4es_MultiTexCoord0;
varying lowp vec4 _gl4es_FrontColor;
varying mediump vec4 _gl4es_TexCoord[1];

highp vec4 ftransform() {
 return 
_gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
}

uniform vec3 g_vHeightFogMins;
uniform vec3 g_vHeightFogMaxs;
uniform mat4 CameraModelViewInverse;
varying vec3 g_WorldVertexPos;
varying vec4 g_EyeVertexPos;


varying float g_fFogFactor;


void main (void)
{
    
vec4 LocalVertexPos=_gl4es_Vertex;
    
g_EyeVertexPos=_gl4es_ModelViewMatrix LocalVertexPos;
    
vec4 WorldVertexPos=CameraModelViewInverse g_EyeVertexPos;
    
g_WorldVertexPos=WorldVertexPos.xyz;
    
    
gl_Position ftransform();


    
float fFogSize=g_vHeightFogMaxs.y-g_vHeightFogMins.y;
    
float fFogDist=WorldVertexPos.y-g_vHeightFogMins.y;
    
g_fFogFactor=1.000000-fFogDist/fFogSize;

    
    
_gl4es_FrontColor=_gl4es_Color;
    
    
_gl4es_TexCoord[0]=_gl4es_TextureMatrix[0]*_gl4es_MultiTexCoord0;

}



Fragment one:

#version 100
precision highp float;
precision highp int;

struct _gl4es_FogParameters {
    
vec4 color;
    
float density;
    
float start;
    
float end;
    
float scale;
};

uniform _gl4es_FogParameters _gl4es_Fog;
varying lowp vec4 _gl4es_FrontColor;
varying mediump vec4 _gl4es_TexCoord[1];

uniform sampler2D Texture0;

varying float g_fFogFactor;

void main (void
{
  
vec4 texcolor=_gl4es_FrontColor;  
  
texcolor*= texture2D(Texture0_gl4es_TexCoord[0].xy);
              
texcolor.rgb=mix(texcolor.rgb,_gl4es_Fog.color.rgb,g_fFogFactor);

  
gl_FragColor=texcolor;
}



So.. now those shaders start to be really small, i hope it can be more understandable what wrong.

Maybe you have any idea of what to change for tests sake ?

I also will try to create some SDL2 simple test cases, which will use those 2 shaders, and see, how they reacts on win32/sdl2 and on aos4/sdl2 (so to rule out more involved parts).

@All
Is anyone can write some test code which will use those 2 shaders ? As i understand there need to be 1 texture be draws, but vertex shader with all that matrix and camera make me feel sad :)


Edited by kas1e on 2019/8/5 9:30:07
Edited by kas1e on 2019/8/5 9:34:47
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Have you tried simplifying the fragment shader down to just the following?
uniform sampler2D Texture0;

// FOG
varying float g_fFogFactor;
// ---

void main (void
{
  
vec4 texcolor;  
  
texcolor texture2D(Texture0gl_TexCoord[0].xy);

  
gl_FragColor=texcolor;
}


If that's not working, then you could try adding: texcolor.a = 1.0;
That's just in case the alpha channel is missing. If the shader above works on AmigaOS 4 (as in, you see the texture), then you can gradually add back in the other code until you hit whatever breaks it.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans

I just totaly remove the fog and from vertex and from fragment now, as well as some other parts. That how they looks like now:

Vertex:

void main (void)
{
    
gl_TexCoord[0]=gl_TextureMatrix[0]*gl_MultiTexCoord0;
    
gl_Position ftransform();
}


Fragment:

uniform sampler2D Texture0;

void main (void
{  
  
gl_FragColor texture2D(Texture0gl_TexCoord[0].xy);
}



So on win32/opengl and on pandora/gl4es i still can see textures, while on amigaos4 still same no-textures.

There is win32 look with those last-reduced shaders:

(press open in new tab for fullsize):

Resized Image


And there is amigaos4 one:

(press open in new tab for fullsize):

Resized Image

As you can see original shaders now very basic, but i assume the problem for us its those ones which generated by gl4es from them and which ogles2 actualy recieved:

Vertex one:

#version 100
precision highp float;
precision highp int;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
uniform highp mat4 _gl4es_TextureMatrix[1];
attribute highp vec4 _gl4es_Vertex;
attribute highp vec4 _gl4es_MultiTexCoord0;
varying mediump vec4 _gl4es_TexCoord[1];

highp vec4 ftransform() {
 return 
_gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
}

void main (void)
{        
    
_gl4es_TexCoord[0]=_gl4es_TextureMatrix[0]*_gl4es_MultiTexCoord0;
    
gl_Position ftransform();    
}


Fragment one:

#version 100
precision highp float;
precision highp int;
varying mediump vec4 _gl4es_TexCoord[1];

uniform sampler2D Texture0;

void main (void
{
  
gl_FragColortexture2D(Texture0_gl4es_TexCoord[0].xy);
}


Probably next step, is to take some sdl2/ogles2 draw-texture tutorial and put those shaders generated by gl4es in, and use them. So if it will works on win32 and fail on aos4 : alilua , almost close then.

Any ideas welcome :) Maybe problems with sampler/texure/arrays mixing ?


Edited by kas1e on 2019/8/5 20:51:28
Edited by kas1e on 2019/8/5 21:15:24
Edited by kas1e on 2019/8/5 21:45:29
Edited by kas1e on 2019/8/5 22:18:59
Edited by kas1e on 2019/8/5 22:19:29
Edited by kas1e on 2019/8/5 22:20:07
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans

So after spend few day on it, we seems found something. So..

Short story:

There is some bug on our part named "something about texture matrixes when arrays is in use".

Long story:

By default gl4es generate shaders with usage of arrays. As i show in last post, there are 2 simple shaders which give a bug on our side:

Vertex:

#version 100 
precision highp float
precision highp int
uniform highp mat4 _gl4es_ModelViewProjectionMatrix
uniform highp mat4 _gl4es_TextureMatrix[1]; 
attribute highp vec4 _gl4es_Vertex
attribute highp vec4 _gl4es_MultiTexCoord0
varying mediump vec4 _gl4es_TexCoord[1]; 

highp vec4 ftransform() { 
 return 
_gl4es_ModelViewProjectionMatrix _gl4es_Vertex


void main (void
{         
    
_gl4es_TexCoord[0]=_gl4es_TextureMatrix[0]*_gl4es_MultiTexCoord0
    
gl_Position ftransform();     
}


Fragment:

#version 100 
precision highp float
precision highp int
varying mediump vec4 _gl4es_TexCoord[1]; 

uniform sampler2D Texture0

void main (void)  

  
gl_FragColortexture2D(Texture0_gl4es_TexCoord[0].xy); 
}


Now, ptitSeb added option LIBGL_NOTEXARRAY (so to not use arrays at all), and with that one BUG IS GONE ! And generated shaders are:

Vertex:

#version 100
precision highp float;
precision highp int;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
uniform highp mat4 _gl4es_TextureMatrix_0;
attribute highp vec4 _gl4es_Vertex;
attribute highp vec4 _gl4es_MultiTexCoord0;
varying mediump vec4 _gl4es_TexCoord_0;

highp vec4 ftransform() {
 return 
_gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
}

void main (void)
{        
    
_gl4es_TexCoord_0=_gl4es_TextureMatrix_0*_gl4es_MultiTexCoord0;
    
gl_Position ftransform();    
}


Fragment:

#version 100
precision highp float;
precision highp int;
varying mediump vec4 _gl4es_TexCoord_0;

uniform sampler2D Texture0;

void main (void
{
  
gl_FragColortexture2D(Texture0_gl4es_TexCoord_0.xy);
}


As you can see bug is gone just once we get rid of arrays usage in matrixes and in texCoords

And that what ptitSeb says:

---
It's something about texture matrixes yes, but what I'm not sure. Because, in a shader view, there is not such thing as a Texture Matrix. It's just a matrix.

I'm unsure what's wrong. You should ask Hans what could be wrong, I don't see any obvious way to explain the issue.
---


And, its not issue of arrays+Tecoords, its exactly issue with arrays+matrixes. I.e. we tried even those shaders and they fail on amigaos4 (i.e. without arrays in texCoords, just in matrixes):

Vertex:
#version 100
precision highp float;
precision highp int;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
uniform highp mat4 _gl4es_TextureMatrix[1];
attribute highp vec4 _gl4es_Vertex;
attribute highp vec4 _gl4es_MultiTexCoord0;
varying mediump vec4 _gl4es_TexCoord_0;

highp vec4 ftransform() {
 return 
_gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
}

void main (void)
{        
    
_gl4es_TexCoord_0=_gl4es_TextureMatrix[0]*_gl4es_MultiTexCoord0;
    
gl_Position ftransform();    
}



Fragment:

#version 100
precision highp float;
precision highp int;
varying mediump vec4 _gl4es_TexCoord_0;

uniform sampler2D Texture0;

void main (void
{
  
gl_FragColortexture2D(Texture0_gl4es_TexCoord_0.xy);
}



So its exactly problem when matrixes used in array. I.e. issue is "uniform highp mat4 _gl4es_TextureMatrix[1];" + "_gl4es_TexCoord_0=_gl4es_TextureMatrix[0]*_gl4es_MultiTexCoord0;"

We think about maybe uniform was not found, but we do some test case , and it's not the case (at least in our simple test case)


Edited by kas1e on 2019/8/6 10:25:51
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Hans is probably not guilty this time, it's more likely me
I added code for GLSL input-arrays en passant back in early 2018 for version 1.18 when Nova finally supported structs and I implemented support for those, but the array-stuff was never tested (actually I didn't even mention it in the relnotes because of this).
Looks like the array-part is broken, at least that would explain what's happening (although a not found uniform would be the kind of problem I had expected first; maybe it's Nova after all - but let me check first ).
Please upload your most minimal test to my FTP, thanks!

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Daniel
Sadly we don't have the most minimal test at moment :( Its all tested inside of gl4es compiled inside frickingshark, and shaders in test are replaced ones in fricking shark.

I was about starting to create some test case which will use exactly those shaders taken as base some simple sdl2+ogles2 example with texture drawing, but didn't gone so far , as shaders in question use matrixes calculation, while that simple test case over which i tried to use them, are not. But maybe it will be easy for you to fix test case to make it work with holding original shaders. As far as i got there need to create some dummy(or not)-matrix-calculation code to make those shaders work as intendent.


There is archive:

http://kas1e.mikendezign.com/aos4/gl4 ... g_testcase_unfinished.zip

At top there commented out original shaders (so you can uncoment them, to see that original code with trawing triangle + texture over it works), and currently uncommented (but of coruse not working too) , those gl4es shaders with arrays which need to use in that test case.

Compile lines are at top of hello_texture_frickingshark_test.cpp file, for os4 it will be:


ppc-amigaos-g++ -athread=native -std=c++11 hello_texture_frickingshark_test.cpp events.cpp camera.cpp -o hello_texture_frickingshark.exe -lSDL2 -lSDL2_image -lpng -ljpeg -ltiff -lwebp -lpthread -lz


Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Thanks, that will do!
The weird part is that an uniform array with just 1 element should not break things inside ogles2 even if there's a bug in the array-support-code in general. But well, I'll check it out.

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Daniel
Quote:

Hans is probably not guilty this time, it's more likely me


Don't worry, i seems found 2 other shader issues :) (not related to arrrays), but waiting confirmation from ptitSeb that on his side on gl4es/pandora all ok before posting them there.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

I was about to suggest you try bypass gl_TextureMatrix[0]... Looks like my hunch was right, but I was a little too slow.

Arrays of matrices should be working in Warp3D Nova (it's tested), but if it isn't then just submit another bug report.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans,Daniel

So about those 2 new bugs i find in fricking shark shaders when we do test it with LIBGL_NOTEXARRAY.

issue #1:

There something with lighting. For first, whole game is "low-lighting". For second, when hit the enemies everything goes black. I.e. on the moment of explosion. Probabaly when fog starts (i.e. other shaders effects). But that bug disappear only when delete fully lighting code from shaders. When remove fog's code from shaders bug still there. Also as you will see on video, all textures are "low-lighting". I.e. textures of ships in menu, and whole gameplay in the levels.

Better to see it on video:

https://youtu.be/DKiTE6OCJjk

As can be seen later in the video, everything but not "water-ripple" effect and "fog / fire" are start to be black. So like only pure textures, and not other "shaders" effects.

issue #2:

There is some "water-ripple" effect : in the menu at begining, and in the game there and there. So, after i game starts, and you watch water-ripple effect somewhere (be it menu, or game), then after about 150-200 seconds, that effect start to disappear bit by bit, until fully not disappear. And only way to get it back its quit and re-run game (So shaders will reinitialized).

I recorder another video to show this : i start 1st level, fly to the moment where water-ripple effect visibly, then press "Esc" (for menu), and waiting 150 seconds.

On video better just move slider to 3:20 and see how from 3:30 it all start:

https://youtu.be/VyS2q1rSqRQ

I asking ptitSeb of course, if for him all fine, he say that yes, with or without LIBGL_NOTEXARRAY all works fine. He have an idea that issue with lighting (issue #1) , maybe a precision issue in the light calculation (and can be the same roots of issue #2). gl4es there use "high precision float in fragment shader" , so maybe related to that.

And there is those shaders in questions (original ones, not glsl, and pretty big ones):

Vertex:

uniform int  g_ActiveLights;
uniform vec3 g_vHeightFogMins;
uniform vec3 g_vHeightFogMaxs;
uniform mat4 CameraModelViewInverse;
varying vec3 g_WorldVertexPos;
varying vec4 g_EyeVertexPos;

#ifdef ENABLE_SKY_SHADOW
uniform vec4 SkyData;
#endif
#ifdef ENABLE_LIGHTING
varying vec4 g_ambdiffspec;
#ifdef ENABLE_NORMAL_MAP
varying vec3 g_TangentSpaceX;
varying vec3 g_TangentSpaceY;
varying vec3 g_TangentSpaceZ;
#else
varying vec3 g_normal
#endif


void PointLight(const in int  i,
                const 
in vec3 ecPosition3,
                const 
in vec3 normal,
                
inout    vec4 ambient,
                
inout    vec4 diffuse,
                
inout    vec4 specular)
{
    
// Compute distance between surface and light position
    
float d length(gl_LightSource[i].position.xyz ecPosition3);
    
vec3 L normalize(gl_LightSource[i].position.xyz ecPosition3);
    
float lambertTerm max(dot(normal,L),0.0);
    
float attenuation 1.0 / (gl_LightSource[i].constantAttenuation +gl_LightSource[i].linearAttenuation +gl_LightSource[i].quadraticAttenuation d);
    
ambient+= gl_LightSource[i].ambient*lambertTerm attenuation;
    
diffuse +=gl_LightSource[i].diffuse*lambertTermattenuation;
    if(
gl_FrontMaterial.shininess>0.0)
    {
        
vec3 E normalize(-ecPosition3);
        
vec3 R reflect(-Lnormal);
        
float specularFactor pow(max(dot(RE), 0.0),gl_FrontMaterial.shininess);
        
specular += gl_LightSource[i].specular *gl_FrontMaterial.specularspecularFactor attenuation;
    }
}
#endif
#ifdef ENABLE_FOG
varying float g_fFogFactor;
#endif 

void GetTagent(const in vec3 normal,
                
out    vec3 tangent)
{
    
vec3 c1 cross(normalvec3(0.00.01.0)); 
    
vec3 c2 cross(normalvec3(0.01.00.0)); 
    
tangent normalize((length(c1)>length(c2))?c1:c2);
}

void main (void)
{
    
vec4 LocalVertexPos=gl_Vertex;
    
g_EyeVertexPos=gl_ModelViewMatrix LocalVertexPos;
    
vec4 WorldVertexPos=CameraModelViewInverse g_EyeVertexPos;
    
g_WorldVertexPos=WorldVertexPos.xyz;

#ifdef ENABLE_LIGHTING
    #ifdef ENABLE_NORMAL_MAP
    
vec3 vTangent;
    
vec3 g_normal=normalize(gl_NormalMatrix gl_Normal);
    
GetTagent(gl_Normal,vTangent);
    
vec3 n g_normal;
    
vec3 t normalize(gl_NormalMatrix vTangent);
    
vec3 b cross(nt);
    
g_TangentSpaceX=t;
    
g_TangentSpaceY=b;
    
g_TangentSpaceZ=n;
    
    
#else
    
g_normal=normalize(gl_NormalMatrix gl_Normal);
    
#endif
#endif
    
    
vec4 amb=vec4(0);
    
vec4 diff=vec4(0);
    
vec4 spec=vec4(0);
    
gl_Position ftransform();
    
#ifdef ENABLE_LIGHTING
    
for(int x=1;x<g_ActiveLights;x++)
    {
        
PointLight(xg_EyeVertexPos.xyzg_normalambdiffspec);
    }
    
g_ambdiffspec=gl_LightModel.ambient+amb+diff+spec*gl_FrontMaterial.specular;
    
#endif

#ifdef ENABLE_FOG
    
float fFogSize=g_vHeightFogMaxs.y-g_vHeightFogMins.y;
    
float fFogDist=WorldVertexPos.y-g_vHeightFogMins.y;
    
g_fFogFactor=1.0-fFogDist/fFogSize;
     
g_fFogFactor*=1.0-step(g_vHeightFogMaxs.x,WorldVertexPos.x);
    
g_fFogFactor*=step(g_vHeightFogMins.x,WorldVertexPos.x);
    
g_fFogFactor=clamp(g_fFogFactor,0.0,1.0);
#endif
    
    
gl_FrontColor=gl_Color;
    
#ifdef ENABLE_TEXTURES
    
gl_TexCoord[0]=gl_TextureMatrix[0]*gl_MultiTexCoord0;
    
#if TEXTURE_UNITS > 1
    
gl_TexCoord[1]=gl_TextureMatrix[1]*gl_MultiTexCoord1;
    
#endif
#endif

#ifdef ENABLE_NORMAL_MAP
    
gl_TexCoord[NORMAL_MAP_TEXTURE_LEVEL]=gl_TextureMatrix[NORMAL_MAP_TEXTURE_LEVEL]*gl_MultiTexCoord2;
#endif
    
#ifdef ENABLE_SKY_SHADOW
    
gl_TexCoord[SKY_TEXTURE_LEVEL].= (g_WorldVertexPos.x/SkyData.y)+SkyData.x;
    
gl_TexCoord[SKY_TEXTURE_LEVEL].= (g_WorldVertexPos.z/SkyData.z);
    
gl_TexCoord[SKY_TEXTURE_LEVEL].0.0;
    
gl_TexCoord[SKY_TEXTURE_LEVEL].0.0;
#endif
#ifdef ENABLE_SHADOWS
    
gl_TexCoord[SHADOW_TEXTURE_LEVEL].dot(g_EyeVertexPosgl_EyePlaneS[SHADOW_TEXTURE_LEVEL]);
    
gl_TexCoord[SHADOW_TEXTURE_LEVEL].dot(g_EyeVertexPosgl_EyePlaneT[SHADOW_TEXTURE_LEVEL]);
    
gl_TexCoord[SHADOW_TEXTURE_LEVEL].dot(g_EyeVertexPosgl_EyePlaneR[SHADOW_TEXTURE_LEVEL]);
    
gl_TexCoord[SHADOW_TEXTURE_LEVEL].dot(g_EyeVertexPosgl_EyePlaneQ[SHADOW_TEXTURE_LEVEL]);
#endif
}


Fragment:

uniform int  g_ActiveLights;
uniform mat4 CameraModelViewInverse;
uniform float CurrentRealTime;

uniform sampler2D Texture0;
uniform sampler2D Texture1;
#ifdef ENABLE_SHADOWS
uniform sampler2DShadow ShadowMap;
#endif
#ifdef ENABLE_NORMAL_MAP
uniform sampler2D NormalMap;
#endif
#ifdef ENABLE_SKY_SHADOW
uniform sampler2D SkyShadowMap;
uniform vec4 SkyData;
#endif

varying vec4 g_EyeVertexPos;

#define LIGHTING_SATURATION 1.5

varying vec3 g_WorldVertexPos;
#ifdef ENABLE_LIGHTING
varying vec4 g_ambdiffspec;
#ifdef ENABLE_NORMAL_MAP
    
varying vec3 g_TangentSpaceX;
    
varying vec3 g_TangentSpaceY;
    
varying vec3 g_TangentSpaceZ;
#else
    
varying vec3 g_normal;
#endif
    
void DirectionalLight(const in int  i,
                      const 
in vec3 normal,
                      
inout    vec4 ambient,
                      
inout    vec4 diffuse,
                      
inout    vec4 specular)
{
    
float nDotVP// normal . light direction
    
float nDotHV// normal . light half vector    
    
float pf// power factor
    
nDotVP max(0.0dot(normal,vec3(gl_LightSource[i].position)));
    
nDotHV max(0.0dot(normalvec3(gl_LightSource[i].halfVector)));
    
pf max(0.0,pow(nDotHVgl_FrontMaterial.shininess));
    
ambient  += gl_LightSource[i].ambient;
    
diffuse  += gl_LightSource[i].diffuse nDotVP;
    
specular += gl_LightSource[i].specular pf;
}

#endif

#ifdef ENABLE_FOG
varying float g_fFogFactor;
#endif 

#ifdef ENABLE_WATER
uniform vec2 WaterMappingSize;
uniform vec2 WaterMappingOffset;

void ApplyWaterEffect(in sampler2D sampler,in vec2 vCoordsout vec3 color)
{
    
// Ripple effect, based on JeGX's post at http://www.geeks3d.com/20110316/shade ... phere-and-ripple-in-glsl/
    // and Adrian Boeing's post at http://adrianboeing.blogspot.com/2011 ... pple-effect-in-webgl.html
    
    
vec2 tc vec2((WaterMappingOffset.x-WaterMappingSize.x)-gl_TexCoord[0].x,WaterMappingSize.y*4.0-gl_TexCoord[0].y);
    
vec2 tc2vec2((WaterMappingOffset.x-WaterMappingSize.x*0.5)-gl_TexCoord[0].x,-gl_TexCoord[0].y);
    
vec2 p = -1.0 2.0*tc;
    
vec2 p2= -1.0 2.0*tc2;
    
    
float len length(p);
    
float len2 length(p2);
    
float ripplesize=cos((len*3.0+CurrentRealTime)*4.0);
    
float ripplesize2=cos((len2*3.0+CurrentRealTime*1.5)*4.0);
    
vec2 uv=tc;
    
uv+=(p/len)*ripplesize*0.03;
    
uv+=(p2/len)*ripplesize2*0.03;
    
uv-=WaterMappingOffset;
    
    
vec3 texcolor=texture2D(sampleruv).xyz;
    
color.rgb texcolor;
    
color.rgb+=texcolor.rgb*max(0.0,ripplesize)*0.05;
    
color.rgb+=texcolor.rgb*max(0.0,ripplesize2)*0.10;    
}
#endif

void main (void
{
  
vec4 texcolor=gl_Color;
  
vec4 finalcolor;
  
float fShadowFactor=1.0;
  
float specfactor=1.0;
  
#ifdef ENABLE_TEXTURES

  #ifdef ENABLE_WATER
  
ApplyWaterEffect(Texture0,gl_TexCoord[0].xy,texcolor.xyz);
  
#else
    
texcolor*= texture2D(Texture0gl_TexCoord[0].xy);
  
#endif
    #if TEXTURE_UNITS > 1
        #ifdef ENABLE_WATER
            
vec3 temptexunit1;
            
ApplyWaterEffect(Texture1,gl_TexCoord[1].xy,temptexunit1);
            
texcolor.rgb*=temptexunit1;
        
#else
            
texcolor*= texture2D(Texture1gl_TexCoord[1].xy);
        
#endif
    #endif
#endif
            
  #ifdef ENABLE_SHADOWS
    
fShadowFactor=shadow2DProj(ShadowMap,gl_TexCoord[SHADOW_TEXTURE_LEVEL]).g;
    
#ifdef ENABLE_SOFT_SHADOWS
        
float offset=3.0;
        
fShadowFactor+=shadow2DProj(ShadowMap,gl_TexCoord[SHADOW_TEXTURE_LEVEL]+vec4(-offset,-offset,0,0)).g;
        
fShadowFactor+=shadow2DProj(ShadowMap,gl_TexCoord[SHADOW_TEXTURE_LEVEL]+vec4(offset,-offset,0,0)).g;
        
fShadowFactor+=shadow2DProj(ShadowMap,gl_TexCoord[SHADOW_TEXTURE_LEVEL]+vec4(-offset,offset,0,0)).g;
        
fShadowFactor+=shadow2DProj(ShadowMap,gl_TexCoord[SHADOW_TEXTURE_LEVEL]+vec4(offset,offset,0,0)).g;
        
fShadowFactor/=5.0;
    
#endif
  #endif
  #ifdef ENABLE_LIGHTING
      
      
vec4 sunamb=vec4(0);
      
vec4 sundiff=vec4(0);
      
vec4 sunspec=vec4(0);
      
vec4 g_sunambdiffspec=vec4(0);
      
      
#ifdef ENABLE_NORMAL_MAP
      // Compute final normal usign the normal map
      
vec3 bump normalizetexture2D(NormalMapgl_TexCoord[NORMAL_MAP_TEXTURE_LEVEL].xy).xyz 2.0 1.0);
      
vec3 N=normalize(bump.x*normalize(g_TangentSpaceY)+bump.y*normalize(g_TangentSpaceX)+bump.z*normalize(g_TangentSpaceZ));
      
#else
      
vec3 N=normalize(g_normal);
      
#endif
            
      
DirectionalLight(0Nsunambsundiff,sunspec);
      
g_sunambdiffspec=sunamb+sundiff+sunspec*gl_FrontMaterial.specular;    
      
      
#ifdef ENABLE_SKY_SHADOW
        
g_sunambdiffspec*=1.0-(texture2D(SkyShadowMapgl_TexCoord[SKY_TEXTURE_LEVEL].xy)*SkyData.a);
      
#endif    
      
      
finalcolor.rgb=clamp(g_ambdiffspec.rgb+g_sunambdiffspec.rgb*fShadowFactor,0.0,LIGHTING_SATURATION);
      
finalcolor.rgb*=texcolor.rgb;
      
finalcolor.a=texcolor.a;
  
#else
    #ifdef ENABLE_SKY_SHADOW
      
fShadowFactor*=1.0-(texture2D(SkyShadowMapgl_TexCoord[SKY_TEXTURE_LEVEL].xy)*SkyData.a).r;
    
#endif    
    
finalcolor=texcolor*fShadowFactor;
  
#endif
    
  
  #ifdef ENABLE_FOG
    
finalcolorvec4(clamp(finalcolor.rgb0.01.0),finalcolor.a);
    
finalcolor.rgb=mix(finalcolor.rgb,gl_Fog.color.rgb,g_fFogFactor);
  
#endif

    
gl_FragColor=finalcolor;
}


Any ideas what can be touched/changed in lightings code in those shaders so to find out what cause issues ?

As positive note in light of bunch of new bugs, shaders start to be the complex ones, that kind of mean we go pretty far with nova/ogles2 :)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
I asking ptitSeb of course, if for him all fine, he say that yes, with or without LIBGL_NOTEXARRAY all works fine. He have an idea that issue with lighting (issue #1) , maybe a precision issue in the light calculation (and can be the same roots of issue #2). gl4es there use "high precision float in fragment shader" , so maybe related to that.

We're using 32-bit floats (that's what the hardware supports), so it's not a precision issue. Do you know which variable is responsible for #1 happening? Once we know which variable is causing it, then we can track down where it's going wrong.

For #2, what value does the CurrentRealTime variable get up to when the waves start reducing. Perhaps the hardware cosine instruction doesn't work well with large values.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
Quote:

Do you know which variable is responsible for #1 happening? Once we know which variable is causing it, then we can track down where it's going wrong.


At moment i only found that if in vertex shader i replace line 91:

g_ambdiffspec=gl_LightModel.ambient+amb+diff+spec*gl_FrontMaterial.specular;

with that:

g_ambdiffspec=vec4(1.0);

Then bug disappear.

So that g_ambdiffspec are faulty variable, have any futher ideas ?:)


Quote:

For #2, what value does the CurrentRealTime variable get up to when the waves start reducing. Perhaps the hardware cosine instruction doesn't work well with large values.


Yeah, put prinf there , and when all starts it show 7.823000 at first, and then increases every redraw or so. Then when effect start to disappear as far as i can see somewhere around 80.xxxxxx .. Maybe a little bit before.

If i put there some static value (i mean in game's code), like 7.823000 for all the time, then, that bug didn't happens as it was : in menu and first level it seems (can be placebo too of course) all fine, but in second level bug 100% still there: i fly over sea , and somewhere in the middle effect ends.

What probabaly mean, its not CurrentRealTime, but probabaly something else. Or CurrentRealTime with something else, and setting it to static only shift problem a little bit.

I also printf WaterMappingSize and WaterMappingOffset uniforms.
EVerything strart with :

WaterMappingSize dMaxU = 50.500000, dMaxV = 8.500000
WaterMappingOffset dMaxU = 0.000110, dMaxV = 0.000000

Then, WaterMappingSize never changes, always the same values. And WaterMappingOffsset dMAxV never changes too , what only changes its WaterMappingOffset's dMaxU. And that one increases well till about 8.xxxxxx and somewhere at this point effect start to disappear.

But nothing abnormal in values ..

And we rechecked again on Pandora/gl4es and on win32 version without gl4es (win32's opengl) : in all cases when we run game with shaders, water effect didn't disappear. That only on our side :(


Edited by kas1e on 2019/8/8 14:32:07
Edited by kas1e on 2019/8/8 18:32:15
Edited by kas1e on 2019/8/8 20:54:10
Edited by kas1e on 2019/8/8 21:00:12
Edited by kas1e on 2019/8/8 21:02:34
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
At moment i only found that if in vertex shader i replace line 91:

g_ambdiffspec=gl_LightModel.ambient+amb+diff+spec*gl_FrontMaterial.specular;

with that:

g_ambdiffspec=vec4(1.0);

Then bug disappear.

So that g_ambdiffspec are faulty variable, have any futher ideas ?:)

Try removing the input variables to that equation one by one to see which one(s) is responsible (e.g., remove gl_LightModel.ambient first, then amb, then the next...). Hopefully it comes down to one of them.

EDIT: Maybe something's going wrong with one of the point light sources? If any value is/becomes "nan" (not a number), then the end value becomes "nan" too, which would probably result in black areas.


Quote:
Yeah, put prinf there , and when all starts it show 7.823000 at first, and then increases every redraw or so. Then when effect start to disappear as far as i can see somewhere around 80.xxxxxx .. Maybe a little bit before. ...

Please submit a bug report for this. It certainly sounds like the cos() function stops working properly when the number gets too big.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
Quote:

Try removing the input variables to that equation one by one to see which one(s) is responsible (e.g., remove gl_LightModel.ambient first, then amb, then the next...). Hopefully it comes down to one of them.


removing only "gl_LightModel.ambient" : everything black all the time. Not only when hit the enemy, but all the time.

removing only "amb" : original bug, i.e. same as full line

removing only "diff" : original bug, i.e. same as full line

removing "amb" + "diff" : better than full line : this time "ground" is not blacks , but all others textures are still.

removing only "spec*gl.FrontMaterial.specular" : original bug, i.e same as full line.

So dunno how to find which one guilty when its mix of them..

Quote:

EDIT: Maybe something's going wrong with one of the point light sources? If any value is/becomes "nan" (not a number), then the end value becomes "nan" too, which would probably result in black areas.


I just tried to add at top of PointLight setting to vec4(1.0), that:

ambient : no changes
ambient + diffuse : no changes
ambient + diffuse + specular : no changes

But then, i tried the same at bottom of function, so :

ambient : no changes

ambient + diffuse : "too dark" initial lighting of game start to be "fine" one, when i hit the enemy. Ground texture not blacks anymore, but all others are

ambient + diffuse + specular : game again starts as too dark, but when i hit enemy, everything start to be normal, instead of black. Then again back to "a bit too dark" , and when hit enemy again goint to "full light".

Its like, there several issues with lighting.

Quote:

Please submit a bug report for this. It certainly sounds like the cos() function stops working properly when the number gets too big.


Sure will do.

But are you sure about ? I mean, don't you need to check it by some test-case or something somehow , so to be sure that it is and so we can stop invistigate that bug futher ?

I just doing another test and pretty possible that your right, but still will share info there, so we all can be sure that we sure :) :

I just tried to set fCurrentTime to some static value, like:

{
fCurrentTime = 85;
iShader->second.m_piShader->AddUniform("CurrentRealTime",fCurrentTime);
}

So, results:

-1 - effect still there
85 - effect still there
86 - effect still there
100 - effect still there
140 - effect start to disappear, begining of visuall differences
150 - effect almost disappeared, just final end before disappear completely
200 - effect disappear completely.
300 - effect disappear completely.
999 - effect disappear completely.

From previous test in another post you can see that when it runs with original code where values increased , then its enough to reach 80-85 for fCurrentTime to make effect disappear. But if i put it statically like this, then there need to be bigger values.

For example, if i do something like :

if (fCurrentTime >75) {fCurrentTime = 100;}; then effect disappear completely once it reach >75 check. But that only when it reach those 75 from 0.

But if i do check like if (fCurrentTime >30) {fCurrentTime = 100;};, then effect didn't disappear when reach 30.

In other words when fCurrentTime value in static for all the time, then value should be a bit bigger to make ripple-effect disappear, while with increased fCurrentTime from 0, that fCurrentTime can be lower to make effect disappear.

But what is for sure, is that its indeed bigger values cause issues. So will create BZ about and put all the info inside.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 ... 29 30 31 (32) 33 34 35 ... 42 »

 




Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project