Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
30 user(s) are online (12 user(s) are browsing Forums)

Members: 0
Guests: 30

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 ... 30 31 32 (33)


Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5316
@Hans
About that lighting bug, maybe it can be seen from another side: there is another differences related to lighting visually, maybe it all have the same roots.

So, if i fully remove lighting code in both shaders, then that how it looks like for

amigaos4:

(open in new tab for fullsize):

Resized Image

win32/opengl , pandora/gl4es:

Resized Image

So, the same at this point without lighting code. That mean that other parts of shader not related to issue i will show now.

Now, there is how looks like shaders "as it", without anything changed, with full lighting code in shaders enabled:

amigaos4:

Resized Image


win32/opengl , pandora/gl4es:

Resized Image

See, on amigaos4 its not only start to be "darker" in whole (and also have that "black" effect as i show on video), but also if you check how looks like "Tanks", you can see they also have issues like "overlighting". Some lines of tanks even not visibly.

To see that issue more better, i set that g_ambdiffspec to vec4(1.0) again (i.e. that how we get rid of black areas before), so its no more "dark" , and you can see how tanks looks like now : they looks like lighting code fully disabled:

Resized Image

Probabaly it's all the same roots , but maybe from this point of view it will bring more ideas about.

As you can see, with fully enabled lighting code, we have bunch of issues :

1). everything black when hit enemy as we discuss before
2). too dark in whole
3). tanks (and other enimies of course, and probabaly some textures too) do have overlighting or something, so some parts (black ones ?) just didn't visibly: probably boscage also a little bit overlighted.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2176
@kas1e

There are two possibilities:
1. A shader compiler bug
2. Corrupt lighting input data

Could you check what happens to the value of g_ActiveLights? This is on a hunch that something blowing up adds an extra light, and that light's data is corrupt. For example, if the explosion's light value happened to be huge and negative, then that would cause the effect we see.

Hans


P.S., Yes, I'm pretty sure that the waves disappearing is caused by the cos() instruction not handling large values. Simple test cases are welcome, though.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5316
@Hans
Quote:

There are two possibilities:
1. A shader compiler bug
2. Corrupt lighting input data


If it was corrypt lighting input data, it should then fail (probabaly) and on gl4es/pandora and on win32/opengl.

Quote:

Could you check what happens to the value of g_ActiveLights?


Yeah.

With original shaders (i.e. when it show us those 3 issues on amigaos4 only) when i just start a game or level (so when everything have too-dark bug), then gl_ActiveLights are "1". The same as if i made shader be with g_ambdiffspec to vec4(1.0), then everything is not too-dark, but gl_ActiveLights value still 1 in both cases, so at least that bug 100% not because of corrupted gl_activelights

Then, when i see enimies, then values start vary, from 1 to 5. When i hit the enemty and have all black screen, values didn't changes much, same 1,2,3,4,5. Not bigger, and not negative. And that the same and with original shader, and when we do g_ambdiffspec be vec4(1.0).

Quote:

This is on a hunch that something blowing up adds an extra light, and that light's data is corrupt. For example, if the explosion's light value happened to be huge and negative, then that would cause the effect we see.


If it was it, it can only explain that one bug, but it didn't explain why everything is too dark (always, just from starting the game), and that textures of enemies overlighted or over-something, as i show on screenshots (that always too, not when i hit them).

Anyway, as gl_ActiveLights as values are small ones, and not negative, its in end probabaly compiler shader bug. Question is how to find out where and why so you can fix it..

Have any more ideas ?:)

Quote:

Yes, I'm pretty sure that the waves disappearing is caused by the cos() instruction not handling large values. Simple test cases are welcome, though.


Done:
http://www.amiga.org/developer/bugreports/view.php?id=427


Through as i suck in shader's programming, i can't create simple test case. But i put relevant fragment shader part to the ticket, so you with your knowledge for sure will be able to made simple test case fast, it if there will be needs. But probabaly internally you can check somehow what happens with cos() anyway faster than creating test case.


_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2176
@kas1e

Quote:
If it was corrypt lighting input data, it should then fail (probabaly) and on gl4es/pandora and on win32/opengl.

Not if the reason for the corrupt data is Amiga-specific (e.g., GLES2 lib bug). The shaders in question use an old variant of GLSL with predefined light uniforms (the gl_LightSource struct array), which modern GLSL doesn't use any more. Fricking shark is probably one of the few programs to use those so far on AmigaOS, and it's entirely possible that there's an issue with them.

Quote:
Then, when i see enimies, then values start vary, from 1 to 5. When i hit the enemty and have all black screen, values didn't changes much, same 1,2,3,4,5. Not bigger, and not negative. And that the same and with original shader, and when we do g_ambdiffspec be vec4(1.0).

What do you mean by "didn't change much?" Does it change at that instant or not? Being in the range of 1-5 doesn't clarify anything.

Quote:
Have any more ideas ?:)

Yes, find out what changes occur with the lights when something is hit. Which light(s) change? Which values change? Knowing what the game is doing with the lights should help track down where it's failing.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5316
@Hans
Quote:

What do you mean by "didn't change much?" Does it change at that instant or not? Being in the range of 1-5 doesn't clarify anything.


Retested again : when you just fly in the level gl_ActiveLights are 1. Once you hit the tank, gl_ActiveLights are 2. Once you hit the paraplane, gl_ActiveLights are 2 sometime 3.

Do you think its better to concetrate on that lighting bug when enemies hits, and not on others 2: "why whole game is too dark with lighting shader" and "why look of textures overlighted" ? At least bug with hit happens only when hit, while other two there always (can be a little bit easer to debug maybe?)



_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2176
@kas1e

Quote:
Retested again : when you just fly in the level gl_ActiveLights are 1. Once you hit the tank, gl_ActiveLights are 2. Once you hit the paraplane, gl_ActiveLights are 2 sometime 3.

Interesting. What happens if you lock gl_ActiveLights to 1? Is there a way for you to print out the values that the lights are set to?

Quote:
Do you think its better to concetrate on that lighting bug when enemies hits, and not on others 2: "why whole game is too dark with lighting shader" and "why look of textures overlighted" ? At least bug with hit happens only when hit, while other two there always (can be a little bit easer to debug maybe?)

Yes, that one's likely to be easier to track down, because it happens under specific circumstances. Hopefully the other two are related, but we can deal with that later.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5316
@Hans
Quote:

Interesting. What happens if you lock gl_ActiveLights to 1?


If i catch all cases when gl_ActiveLights is more than 1, and then set it to 1 before calling adduniform(), then bug with "all black when hit" disappeared !


Quote:

Is there a way for you to print out the values that the lights are set to?


As far as i can see there is only one uniform in shader about lighting (that gl_ActiveLights), so that one i can printf easy from source code of game, but other ones you mean probabaly shaders values, and they probabaly very hard to print. I remember reading in google that its all hard, and ppls only somehow print it like "drawing on screen", etc.


EDIT: oh, and that i notice now, its probabaly another issue with lighting. Originally, when shaders works as expected, when you hit enemy, everything around have some lighting effect, which we didnt' have.

On win32/opengl and on pandora/gl4es, does not matter if you set gl_ActiveLighting to 1 or not for all the time : that effect still here, and visually not much changes. If it 1 for all time, or varies.

Its like, whole lighting dind't work.


Edited by kas1e on 2019/8/13 7:47:08
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2176
@kas1e

Quote:
If i catch all cases when gl_ActiveLights is more than 1, and then set it to 1 before calling adduniform(), then bug with "all black when hit" disappeared !

Okay, so there's definitely a problem with the additional lights. It could still be either corrupt uniform data passed to the GPU, or a shader compiler issue.

Quote:
As far as i can see there is only one uniform in shader about lighting (that gl_ActiveLights), so that one i can printf easy from source code of game, but other ones you mean probabaly shaders values, and they probabaly very hard to print. I remember reading in google that its all hard, and ppls only somehow print it like "drawing on screen", etc.


The lighting parameters that end up in the gl_LightSource array are set via glLightfv(). This is a legacy OpenGL function which GL4ES must somehow process to work with GLES2. For that matter, the raw shaders must be modified before being passed to the GLES2 library to add the legacy gl_LightSource uniform.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5316
@Hans
Ok, will go then that way: will remove from original shaders everything which is not light: fog, shadows, water-ripple, etc. Then will strip light functions till small, but which still give on os4 black-when-hit, but on win32/oopengl and pandora/gl4es still not. Then we can continue , but since then will post shaders after gl4es conversion: that indeed will be better than checking original shaders which later convering by gl4es and add/remove/regroup things.

Will take few hours

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a story that hasn't been written yet
Posts: 3433
@kas1e

And you say you are "shitty" with shader writing?

I can't even imagine touching this stuff, let alone altering it to a working stripped down test version...

_________________
If slaughterhouses had glass walls, everyone would be a vegetarian. ~ Sir Paul McCartney
-
Did everything just taste purple for a second? ~ Philip J. Fry
-
Ain't got no cash, ain't got no style, ladies vomit when I smile. ~ Dr.
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5316
@Hans
So was able to strip the shaders so "black-when-hit" bug still there, and that how looks like shaders which are converted by gl4es and sended to ogles2:

Vertex one:

#version 100
precision highp float;
#define _gl4es_MaxLights 8
precision highp int;
uniform highp mat4 _gl4es_ModelViewMatrix;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
uniform highp mat4 _gl4es_TextureMatrix_0;
uniform highp mat3 _gl4es_NormalMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
attribute highp vec4 _gl4es_MultiTexCoord0;
attribute highp vec3 _gl4es_Normal;
struct _gl4es_LightSourceParameters
{
   
vec4 ambient;
   
vec4 diffuse;
   
vec4 specular;
   
vec4 position;
   
vec4 halfVector;
   
vec3 spotDirection;
   
float spotExponent;
   
float spotCutoff;
   
float spotCosCutoff;
   
float constantAttenuation;
   
float linearAttenuation;
   
float quadraticAttenuation;
};
uniform _gl4es_LightSourceParameters _gl4es_LightSource[_gl4es_MaxLights];
struct _gl4es_LightModelParameters {
  
vec4 ambient;
};
uniform _gl4es_LightModelParameters _gl4es_LightModel;
struct _gl4es_MaterialParameters
{
   
vec4 emission;
   
vec4 ambient;
   
vec4 diffuse;
   
vec4 specular;
   
float shininess;
};
uniform _gl4es_MaterialParameters _gl4es_FrontMaterial;
uniform _gl4es_MaterialParameters _gl4es_BackMaterial;
varying lowp vec4 _gl4es_FrontColor;
varying mediump vec4 _gl4es_TexCoord_0;

highp vec4 ftransform() {
 return 
_gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
}


uniform int  g_ActiveLights;
varying vec4 g_EyeVertexPos;

varying vec4 g_ambdiffspec;
varying vec3 g_normal


void PointLight(const in int  i,
                const 
in vec3 ecPosition3,
                const 
in vec3 normal,
                
inout    vec4 ambient,
                
inout    vec4 diffuse,
                
inout    vec4 specular)
{
    
    
float d length(_gl4es_LightSource[i].position.xyz ecPosition3);
    
vec3 L normalize(_gl4es_LightSource[i].position.xyz ecPosition3);
    
float lambertTerm max(dot(normal,L),0.000000);
    
float attenuation 1.000000 / (_gl4es_LightSource[i].constantAttenuation +_gl4es_LightSource[i].linearAttenuation +_gl4es_LightSource[i].quadraticAttenuation d);
    
ambient+= _gl4es_LightSource[i].ambient*lambertTerm attenuation;
    
diffuse +=_gl4es_LightSource[i].diffuse*lambertTermattenuation;
    if(
_gl4es_FrontMaterial.shininess>0.000000)
    {
        
vec3 E normalize(-ecPosition3);
        
vec3 R reflect(-Lnormal);
        
float specularFactor pow(max(dot(RE), 0.000000),_gl4es_FrontMaterial.shininess);
        
specular += _gl4es_LightSource[i].specular *_gl4es_FrontMaterial.specularspecularFactor attenuation;
        
    }
}


void main (void)
{
    
vec4 LocalVertexPos=_gl4es_Vertex;
    
g_EyeVertexPos=_gl4es_ModelViewMatrix LocalVertexPos;


    
g_normal=normalize(_gl4es_NormalMatrix _gl4es_Normal);

    
    
vec4 amb=vec4(0);
    
vec4 diff=vec4(0);
    
vec4 spec=vec4(0);
    
gl_Position ftransform();

    for(
int x=1;x<g_ActiveLights;x++)
    {
        
PointLight(xg_EyeVertexPos.xyzg_normalambdiffspec);
    }
    
g_ambdiffspec=_gl4es_LightModel.ambient+amb+diff+spec*_gl4es_FrontMaterial.specular;

    
    
_gl4es_FrontColor=_gl4es_Color;
    

    
_gl4es_TexCoord_0=_gl4es_TextureMatrix_0*_gl4es_MultiTexCoord0;

}


Fragment one:

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

uniform int  g_ActiveLights;

uniform sampler2D Texture0;

varying vec4 g_ambdiffspec;
varying vec3 g_normal;
    

void main (void
{
         
vec4 texcolor=_gl4es_FrontColor;
         
vec4 finalcolor;
   
  
      
texcolor*= texture2D(Texture0_gl4es_TexCoord_0.xy);

      
vec4 sunamb=vec4(0);
      
vec4 sundiff=vec4(0);
      
vec4 sunspec=vec4(0);
     
      
      
vec3 N=normalize(g_normal);

      
finalcolor.rgb=clamp(g_ambdiffspec.rgb,0.000000,1.500000);
          
finalcolor.rgb*=texcolor.rgb;
          
finalcolor.a=texcolor.a;
  
          
gl_FragColor=finalcolor;
}


As i see, vertex one still have arrays for uniform, and that is exactly that uniform _gl4es_LightSourceParameters _gl4es_LightSource[_gl4es_MaxLights];

So maybe problem still because of uniforms arrays ! It looks just the same as it was before : when all textures was black. And once we get rid of arrays usage there, textures appears to be visibly. Now, there is another uniform arrays, which also give us "black-when-hit", so maybe it's still the same issues ?

I ask ptitSeb, if it for sake of tests possible to get rid of uniform's array usage there , and he say that:

Quote:

Don't forget all those variable are normaly "built-in" in OpenGL, and gl4es already need to track them. Tranforming the array to non-array basically double the work (tracking the array and non-array form). Also, more importantly, on the shader side, you can see the lights array are accessed by variable. It's inside a function called from inside a loop on the number of active lights (look at the PointLight function in the vertex shader). Unrolling that will result in a mess of a shader: that really is difficult, and will not result in the same shader anyway.

Lightning most often needs arrays, because you most of the time have more than 1 light.


What mean, that even if the roots of problem probabaly the same (seems very possible) because of that non-working uniform's arrays, then we can't fast-check-test it, and only can test it when uniform arrays issue will be fixed.

So cross the fingers that Daniel can find the roots , then we can test fistly if all works with arrays, and then we can see how lighting start to works (or not), and how other lighting issues will looks like.

Oh, btw , need to mention, that it's not just an array of uniform, but an array of uniform structure (!) there, so can be probably some other bug with the same "uniform arrays" roots.


Edited by kas1e on 2019/8/13 19:33:53
Edited by kas1e on 2019/8/13 19:47:00
Edited by kas1e on 2019/8/13 19:48:08
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2176
@kas1e

Nice job, we're getting closer to discovering the root cause. It definitely looks like a uniform array of structures problem.

I just checked, and I have a test for uniform arrays of structures. It's a relatively simple one (a single uniform variable with a struct containing 3 floats), though, so there could still be a bug in there.

I agree with ptitSeb that reworking the code to remove the arrays would create a mess. It's not worth the effort.

For now, I can't think of anything else to try to narrow it down further.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5316
@Hans, Capehill

Good news about water-ripple bug effect, while its probabaly the easest bug from all, still ..

So, i was able to create simple test case with _VERY_ simplefied version of ripple-water effect. I grab the Hans tutorial 3 (drawing texture), reduce gl4es shaders very much + adapt them a little as well as adapt main.cpp so it set CurrentTime uniform in a loop, and violla, bug is 100% reproducable on amigaos4 once CurrentValue hit _exactly_ 400. Dunno why 400, but it is.

I firstly create it for win32/opengles(angle) (yeah, that really handy now to test bugs when you have ability to run 1:1 the same code on both win32 and aos4), and there is no such bug of course. Currenttime value increased as much as i wish without problems (i tested till 2000, all fine). While on amigaos4, once 400 is hit: bum, nothing happens, effect stops.

There is archive with test case:

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


win32(x64 with all .dlls inside) and amigaos4 versions, source code and binaries included. Just unpack, run Effect_bug.exe, and just hold any button when window with texture active: In the shell you will see printouts of currentvlaue (a = xxx , this is that fCurrentTime) , and once it hit 400 effect disappear. On win32 all fine, i test even till 2000.

Shaders in question start to be really small.

Vertex one:

#version 100
precision highp float;
precision highp int;
attribute highp vec4 _gl4es_Vertex;
attribute highp vec4 _gl4es_MultiTexCoord0;
varying mediump vec4 _gl4es_TexCoord_0;
varying lowp vec4 _gl4es_FrontColor;

highp vec4 ftransform() {
 return 
_gl4es_Vertex;
}



void main (void)
{
    
    
_gl4es_TexCoord_0=_gl4es_MultiTexCoord0;
    
gl_Position ftransform();

}


Fragment one:

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

uniform float CurrentRealTime;

uniform sampler2D texSampler;

void ApplyWaterEffect(in sampler2D sampler,in vec2 vCoordsout vec3 color)
{
        
    
vec2 tc vec2(_gl4es_TexCoord_0.x,_gl4es_TexCoord_0.y);    
    
    
float len length(-1.000000 2.000000*tc);
    
float ripplesize=cos((len*3.000000+CurrentRealTime)*4.000000);
    
vec2 uv=tc;
    
uv+=ripplesize*0.030000;

    
    
color.rgb texture2D(sampleruv).xyz;
}

void main (void
{
   
vec4 texcolor=_gl4es_FrontColor;

   
ApplyWaterEffect(texSampler,_gl4es_TexCoord_0.xy,texcolor.xyz);
   
   
gl_FragColortexcolor;

   
}


They can be reduced even more, just effect will a bit more sucky , but for tests its enough for sure.

@Hans
Now its probabaly one of the best bug-reports ! :) Hope you will start to works on nova soon.

ps. will add that testcase to BZ just in case.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5316
@Hans
And it's not only cos() , it also sin() behave exactly the same. I.e all fine on win32/opengl(angle) and on pandora/gl4es, but give same issue on aos4. And it also stops on the same currentime value as cos().

I also shorten fragment shader even more, now effect looks wrong of course, but that not matter, what matter that i still can see how cos() or sin() stop working. I remove all * 4, all + and so on, so now function which use cos()/sin() looks just like this:

void ApplyWaterEffect(in sampler2D sampler,in vec2 vCoordsout vec3 color)
{

    
vec2 tc vec2(_gl4es_TexCoord_0.x,_gl4es_TexCoord_0.y);
  
    
vec2 uv=tc+sin(CurrentRealTime);

    
color.rgb texture2D(sampleruv).xyz;
    
}


Now, even with such a small function, once we do 1600 loops, everything stops. For both cos() and sin(). Before it was 400 because in shader's code we multiply it and so on.

Is there anything you can think of , why "1600" exactly are stop factor to broke sin() and cos() ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top


« 1 ... 30 31 32 (33)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project