Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
69 user(s) are online (47 user(s) are browsing Forums)

Members: 0
Guests: 69

more...

Headlines

 
  Register To Post  

« 1 ... 33 34 35 (36) 37 38 39 ... 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
@Daniel
Some good and bad news on crash front about FBO in supertuxkart:

That broken look of cars when we use LIBGL_RECYCLEFBO env was indeed because of gl4es, but then, once ptitSeb fix it, and it start to show cars correcly, it start now crashes the same as without LIBGL_RECYCLEFBO ! Damn :( With the same:

[error] Irrlicht: FBO has one or serveral incomplete image attachements
[error] Irrlicht: FBO error

So the bad news that we didn't find roots of crash, and the good news, that it some general issue, which is NOT fixed by usage of LIBGL_RECYCLEFBO, and roots of crash somewhere else and more general just than regrouping/reusing fbos..


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
Then I'll have to inspect it in depth to find the cause and whether it's related to ogles2 or Nova or whatever. Please prepare a nice package for me and upload that to my FTP server, as usual Also, if you have fresh trace-logs with the latest glsnoop, hand'em over please!

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
All done !

game:
reports_here/supertuxkart.lha

full trace/profile from start to crash:
reports_here/supertuxkart_tracelog.txt

Through to note : when you start it, it will take about 100 seconds to load till menu (loading screen will appears with some progress, but still).

I hope to reduce loading speed if possible somehow (in snoopy log i can see lots of GetFilePosition/ChangeFilePosition , which probabaly mean fseek() / ftell() / etc, which are that slow on our side by some reassons). Not so matter now anyway, just saying so you know how it should be for now.

So just unpack, run, wait 100 seconds, then choice "single player" , and try to move mouse cursor over cars. It can crash immediately, or after 2-3 cars (random luck).

Sometime, in very rare cases, you are able to choice car and start play, but it just 1:5 times.

After ptitSeb fix rendering with LIBGL_RECYCLEFBO and we start to have same crashes as without that environment, ptitSeb bring idea that maybe FBO needs some pause to be dealt with, and as test we do flush of all GL operation before attaching a texture to the FBO : but that sadly didn't help and crash still here (but that probabaly also reduce a bit route to search on our side ?)

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
@Daniel
Oh, found i way how to make for you faster loading , without needs to wait 100 seconds (by faster i mean 10-15 seconds instead of 100) : just remove directories "data/karts/konqi" and "data/karts/sara". First one use 19mb .b3d file, and second one 8mb .b3d file, and seems that our realisation of ftell() in newlib, suck some amiga1200, and very slow. At least in the snoopy log i can see a loooot of those GetFilePosition()/ChangeFilePosition() calls, which probabaly mean newlib's ftell().

In other words, remove those 2 directories, and loading will be 10-15 seconds, very good for tests.

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
@Daniel
Hate to bring your attention back to some old bug (probabaly), but i think we didn't fix fully issue with which we fight times back in Lugaru and which you fix in 2019-03-30 called "one of the 32bit-step-hashers had a problem with small data-packets".

So while Lugaru is correct now, i firstly found the same (i hope its the same) issue in one place of new SuperTuxKart. I didn't take an attention to that at first, as it happens vere rare, so i think at first that maybe something with STK's code.

But then, today i notice very clear that issue in the RTCW-Reboorn too, so seems that issue indeed there. I also very carefull check STK and yeah, it have the same issue too.

See screenshots (all taken from ogles 2.10 (09/19/2019) , press open in new tab for fullsize):

1. RTCW-Reboorn (see sky in the middle, remind issue in Lugaru skybox we had before):

Resized Image

Resized Image

2. SuperTuxKart (see vertical line in the middle of sky on all screenshots):

Resized Image

Resized Image

Resized Image


Should to note, that broken geometry not visibly very well as it was when we fight with Lugaru's sky-box issues when it was all the time right in the face. Now it happens very rare, but still happens as can be seen.


Edited by kas1e on 2019/10/7 14:37:14
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
Regarding the FBO issue: I found that the respective FBO becomes "incomplete". However, the parameters seem to be correct, I still didn't find out what's causing this.

Regarding the skybox issue you just brought up:
from the screenshots it looks as if there were two different issues. Two of the Tuxkart screenshots look like the hash problem reappearing indeed. However, to me the other skyboxes seem to be correct regarding the geometry (the clouds' edges seem to match) but only the coloring seems to be wrong. But this can be coincidence as well.
I've put a test-lib on my ftp for you, please check out if that makes the problems disappear.

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
Oh i was too fast ! I tested that version of supertuxkart on win32, and that vertical line is here ! Check this out:

Resized Image

So at least with STK, its or problems in STK itself, or, what very unlucky, and in win32 and in our opengl driver, which is imho unpossible :) So imho that STK. But i anyway test it with no-hash version of library, and issue still here as expected. So imho that one we can no worry about, as if it on win32 too, then..


As with RTCW-Reboorn : tested no-hash version of library with that game as well, and bug still there too.

But now, after STK one was in the STK itself (i think it very unlucky that its win32 drivers too), i start to fear that maybe issue with RTCW-Reboorn also the game's code too..

Will try to setup win32 version of Reboorn, to see how it 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
@Daniel
Well, that was another unexpected (or expected :) ) thing, but RTCW Reboorn bug is also not on our side, but also on win32 ! I.e. that the game's code bug as with SuperTuxKart, see:

Resized Image

And that not all. Remember those issues with "Dots on the wall" sometimes ? There is win32 version of it:

Resized Image

Resized Image

And that not all ! Remember issue with "blink triangles overwrite each others in some place" ? There is win32 version of it too:

Resized Image

Damny crap it mean ALL those issues in RTCW-Reboorn are games code issues, and not our ones !

And that is good news : our drivers are fine in that terms :)

I also subscribe to those guys who make this Reboorn, they release privately some patches from time to time, will see if / when they fix all those issues , and probabaly after Huno can build new version of it.

But anyway, how relief is it : all bugs in RTCW Reboorn is not our faults

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
(leaning back, putting feet up) Wow, that's fantastic news - at least for us Once more: thanks for all that (re-)testing!

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
@All
In light of some hope that there will be warp3dnova fixes, working on another game, and find out, that seems some Fog shader didn't works as expected.

At least, i _think_ it can be shaders, but can be that something also in the glFog/glFogi, dunno.

So, that what we have visually when we compile the same kind of simple sdl1/opengl test code (press open in new tab for fullsize images):

1. Win32 / OpenGL

Resized Image


2. Linux / Mesa

Resized Image

3. Linux / GL4ES

Resized Image

4. AmigaOS4 / MiniGL

Resized Image

5. AmigaOS4 / GL4ES (bah!)

Resized Image


As can be seen, GL4ES are not guilty : on linux same code works. Whole code also not guilty : it works everywhere. Even on MiniGL it works, which mean that "fog" itself can works on warp3dnova (as minigl i test works over warp3dnova, but minigl didn't use shaders while working over warp3dnova). But gl4es version on amigaos4 are use shaders of course, and fail visually. So probabaly because of shaders (or, if something with glFog/etc , which is probabaly not the case).

Now, there is 2 shaders we have generated for that test case:

Vertex one:

#version 100
precision mediump float;
precision mediump int;
uniform highp mat4 _gl4es_ModelViewMatrix;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
uniform highp mat3 _gl4es_NormalMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute highp vec3 _gl4es_Normal;
struct _gl4es_LightModelProducts
{
   
vec4 sceneColor;
};
uniform _gl4es_LightModelProducts _gl4es_FrontLightModelProduct;
uniform _gl4es_LightModelProducts _gl4es_BackLightModelProduct;
struct _gl4es_FogParameters {
    
lowp vec4 color;
    
mediump float density;
    
mediump float start;
    
mediump float end;
    
mediump float scale;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying vec4 Color;
struct _gl4es_FPELightSourceParameters1
{
   
highp vec4 specular;
   
highp vec4 position;
   
highp vec3 spotDirection;
   
highp float spotExponent;
   
highp float spotCosCutoff;
   
highp float constantAttenuation;
   
highp float linearAttenuation;
   
highp float quadraticAttenuation;
};
struct _gl4es_FPELightSourceParameters0
{
   
highp vec4 specular;
   
highp vec4 position;
   
highp vec3 spotDirection;
   
highp float spotExponent;
   
highp float spotCosCutoff;
};
struct _gl4es_LightProducts
{
   
highp vec4 ambient;
   
highp vec4 diffuse;
   
highp vec4 specular;
};
uniform highp float _gl4es_FrontMaterial_shininess;
uniform highp float _gl4es_FrontMaterial_alpha;
uniform _gl4es_FPELightSourceParameters1 _gl4es_LightSource_0;
uniform _gl4es_LightProducts _gl4es_FrontLightProduct_0;
varying mediump float FogF;

void main() {
vec4 vertex _gl4es_ModelViewMatrix _gl4es_Vertex;
vec3 normal _gl4es_NormalMatrix _gl4es_Normal;
gl_Position _gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
Color _gl4es_FrontLightModelProduct.sceneColor;
highp float att;
highp float spot;
highp vec3 VP;
highp float lVP;
highp float nVP;
highp vec3 aa,dd,ss;
highp vec3 hi;
VP _gl4es_LightSource_0.position.xyz vertex.xyz;
lVP length(VP);
att 1.0/(_gl4es_LightSource_0.constantAttenuation lVP*(_gl4es_LightSource_0.linearAttenuation _gl4es_LightSource_0.quadraticAttenuation lVP));
VP normalize(VP);
aa _gl4es_FrontLightProduct_0.ambient.xyz;
nVP dot(normalVP);
dd = (nVP>0.)?(nVP _gl4es_FrontLightProduct_0.diffuse.xyz):vec3(0.);
hi normalize(VP vec3(0.0.1.));
lVP dot(normalhi);
ss = (nVP>0. && lVP>0.)?(_gl4es_FrontLightProduct_0.specular.xyz):vec3(0.);
Color.rgb += att*(aa+dd+ss);
Color._gl4es_FrontMaterial_alpha;
Color.rgb clamp(Color.rgb0.1.);
float fog_c abs(vertex.z);
FogF clamp((_gl4es_Fog.end fog_c) * _gl4es_Fog.scale0.1.);
}


Fragment one:

#version 100
precision mediump float;
precision mediump int;
struct _gl4es_FogParameters {
    
lowp vec4 color;
    
mediump float density;
    
mediump float start;
    
mediump float end;
    
mediump float scale;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying vec4 Color;
varying mediump float FogF;
void main() {
vec4 fColor Color;
fColor.rgb mix(_gl4es_Fog.color.rgbfColor.rgbFogF);
gl_FragColor fColor;
}



And there is full archve with source code of test case, and binaries for all platforms:

http://kas1e.mikendezign.com/aos4/gl4es/fog_test.zip

Any ideas ? Maybe someone can see from the code and look of something which may cause that ? Visually as can be seen there like no fog working at all.

I may try to reduce test cose more-and-more to simplify shaders till the moment while they still didn't works as expected, but maybe someone may see something already or have an idea about.

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
I was able to reduce init() part to just that (to still see that it works on win32 & linux/gl4es and didnt on amigaos4/gl4es), by disabling more fog parameters and lighting:

void init()
{
    
        
glClearColor(.5,.5,.5,1.);      //background color and alpha
        
glMatrixMode(GL_PROJECTION);
        
glLoadIdentity();
        
gluPerspective(45,640.0/480.0,1.0,500.0);
        
glMatrixMode(GL_MODELVIEW);
        
glEnable(GL_DEPTH_TEST);
        
cube loadObject("test.obj");
        
        
glEnable(GL_FOG);
        
        
float color[] = {.5,.5,.5,1.};
        
glFogfv(GL_FOG_COLORcolor);
        
float col[] = {1.,1.,1.,1.};
        
glLightfv(GL_LIGHT0GL_DIFFUSEcol);
}


So, shaders are now:

vertex one:

#version 100
precision mediump float;
precision mediump int;
uniform highp mat4 _gl4es_ModelViewMatrix;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
struct _gl4es_FogParameters {
    
lowp vec4 color;
    
mediump float density;
    
mediump float start;
    
mediump float end;
    
mediump float scale;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying vec4 Color;
varying mediump float FogF;

void main() {
vec4 vertex _gl4es_ModelViewMatrix _gl4es_Vertex;
gl_Position _gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
Color _gl4es_Color;
float fog_c abs(vertex.z);
FogF clamp(exp(-_gl4es_Fog.density fog_c), 0.1.);
}


Fragment one:

#version 100
precision mediump float;
precision mediump int;
struct _gl4es_FogParameters {
    
lowp vec4 color;
    
mediump float density;
    
mediump float start;
    
mediump float end;
    
mediump float scale;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying vec4 Color;
varying mediump float FogF;
void main() {
vec4 fColor Color;
fColor.rgb mix(_gl4es_Fog.color.rgbfColor.rgbFogF);
gl_FragColor fColor;
}


So even with that simple ones bug stil lthere

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
And now we replaced mix() from fragment shader on non-mix version doing the same, as well as add setting of alpha after (just in case it looses somewhere), as well as remove from the structs unused fields (just in case too), and now shaders are really small ones, and still give that bug:

Vertex one:

#version 100
precision mediump float;
precision mediump int;
uniform highp mat4 _gl4es_ModelViewMatrix;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
struct _gl4es_FogParameters {
    
vec4 color;
    
mediump float density;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying lowp vec4 Color;
varying mediump float FogF;

void main() {
vec4 vertex _gl4es_ModelViewMatrix _gl4es_Vertex;
gl_Position _gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
Color _gl4es_Color;
float fog_c abs(vertex.z);
FogF clamp(exp(-_gl4es_Fog.density fog_c), 0.1.);
}


Fragment one:

#version 100
precision mediump float;
precision mediump int;
struct _gl4es_FogParameters {
    
vec4 color;
    
mediump float density;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying lowp vec4 Color;
varying mediump float FogF;
void main() {
vec4 fColor Color;
fColor.rgb _gl4es_Fog.color.rgb*(1.0-FogF)+fColor.rgb*FogF;
fColor.Color.a;
gl_FragColor fColor;
}


What it can be ?:) Where ? abs() and clamp() probabaly all should be fine as they basic ?

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
Hello

1) Have you tried to let the Vertex shader unchanged and just let something like that in the Frag shader's main()

gl_FragColor=vec4(FogF,FogF,FogF,1.0);

So we will see if vertex shader generate a good FogF value

2) then try
gl_FragColor=_gl4es_Fog.color;
to see if the uniforms' fog colour is really send to the shaders

3) then try
gl_FragColor=vec4( _gl4es_Fog.density ,_gl4es_Fog.density ,_gl4es_Fog.density ,1.0);
to see if the uniforms' fog density is really send to the shaders

Note: putting the value to debug in gl_FragColor is a good way to find a shader problem as it can be read in the resulting picture in the RGB pixel value

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
@thellier

I tried for sake of getting rid of exp() thing in vertex shader Linear fog type, and then your first test. So shaders now looks like this:

Vertex one:

#version 100
precision mediump float;
precision mediump int;
uniform highp mat4 _gl4es_ModelViewMatrix;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
struct _gl4es_FogParameters {
    
lowp vec4 color;
    
mediump float density;
    
mediump float start;
    
mediump float end;
    
mediump float scale;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying lowp vec4 Color;
varying mediump float FogF;

void main() {
vec4 vertex _gl4es_ModelViewMatrix _gl4es_Vertex;
gl_Position _gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
Color _gl4es_Color;
float fog_c abs(vertex.z);
FogF clamp((_gl4es_Fog.end fog_c) * _gl4es_Fog.scale0.1.);
}


Fragment one:

#version 100
precision mediump float;
precision mediump int;
// FPE_Shader generated
varying lowp vec4 Color;
varying mediump float FogF;
void main() {
gl_FragColor vec4(FogF,FogF,FogF,1.0);
}



Bug still there. Visually nothing changes in compare with original shaders.

So it seems that its vertex shader is not generate a good FogF value, right ? And there is no point to check 2) and 3) then , but something in vertex shader instead ?

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
>And there is no point to check 2) and 3)
I dont agree: perhaps _gl4es_Fog.density & _gl4es_Fog.color are not correctly transmited to BOTH shaders but you can only display it with frag shader with gl_FragColor=_gl4es_Fog.color;

BTW are you sure the "mediump" are needed in struct _gl4es_FogParameters ?

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
Quote:

I dont agree: perhaps _gl4es_Fog.density & _gl4es_Fog.color are not correctly transmited to BOTH shaders but you can only display it with frag shader with gl_FragColor=_gl4es_Fog.color;


Done all 3 checks then (press open image in fullscreen for fullsize):

1) gl_FragColor=vec4(FogF,FogF,FogF,1.0);

Resized Image

2) gl_FragColor=_gl4es_Fog.color;

Resized Image

3). gl_FragColor=vec4( _gl4es_Fog.density ,_gl4es_Fog.density ,_gl4es_Fog.density ,1.0);

Resized Image

The only differences i see visually its when 1) is used. Cube at least have changes something and not solid black. While of course still wrong, as it should be just like this:

Resized Image


Any more ideas ?:)

Maybe data transfert between vertex shader and fragment shader goes wrong (the "varying" process) ? But then, we already use in gl4es "varying" a lot as well, as it generate far more complex shaders for other games (like neverball, frickingshark, etc)


Edited by kas1e on 2019/11/5 15:11:25
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
@all
So as next check i doing some thing Daniel have idea about: To check if the data arrived correctly in the vertext shader.

So we do the following: Instead of using fogstruct.color in the frag shader, transfer the color from the struct into a fresh vec4 varying in the vertex shader and use that one in the frag shader. If the correct color shows up then Novas varying handling is broken.

I.e. like that:

Vertex:

#version 100
precision mediump float;
precision mediump int;
uniform highp mat4 _gl4es_ModelViewMatrix;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
struct _gl4es_FogParameters {
    
lowp vec4 color;
    
mediump float density;
    
mediump float start;
    
mediump float end;
    
mediump float scale;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying vec4 Color;
varying mediump float FogF;
varying mediump vec4 testV;
 
void main() {
vec4 vertex _gl4es_ModelViewMatrix _gl4es_Vertex;
gl_Position _gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
Color _gl4es_Color;
testV _gl4es_Fog.color;
float fog_c sqrt(vertex.z*vertex.z);
FogF clamp((_gl4es_Fog.end fog_c) * _gl4es_Fog.scale0.1.);
}


Fragment:

#version 100
precision mediump float;
precision mediump int;
struct _gl4es_FogParameters {
    
lowp vec4 color;
    
mediump float density;
    
mediump float start;
    
mediump float end;
    
mediump float scale;
};
uniform _gl4es_FogParameters _gl4es_Fog;
// FPE_Shader generated
varying vec4 Color;
varying mediump float FogF;
varying mediump vec4 testV;
void main() {
vec4 fColor Color;
fColor.rgb mix(_gl4es_Fog.color.rgbfColor.rgbFogF);
gl_FragColor testV;
}


So, it show me color of cube the same as background. Probably that what Daniel expect it to be by meaning "if it show the correct color".

And i can even change the color to one i need, like:

testV = _gl4es_Fog.color;
testV.g = 0.3;

And it show correctly changes.

Then, i going back to original shaders to check that final FogF value in Vertex.

What i do, is instead of:

FogF = clamp((gl_Fog.end - fog_c) * gl_Fog.scale, 0., 1.);

i doing just:

FogF = 0.1;

So, i can see that "FogF" value works in fragment shader, and with that 0.1, it show me what it should show for 0.1 (almost the same color of cube as background, all fine then).

But once i add there anything from the gl_Fog. structure, then i have black cube. For example, just if i do something like this:

FogF = 0.1 - fog_c;

then cube is Black.

if just:

FogF = 0.1 + fog_c;

then cube is fully white.

Not sure what happens , but probabaly all of this mean that there is issue with struct varying. And maybe that is somehow related to issue we have with FrickingShark's shaders few pages back. FrickingShark's ones wasn't about "varying struct" of course, but it do have "varying of modelmatrixes" too, so cross the fingers its all can be somehow related.


Edited by kas1e on 2019/11/5 21:37:07
Edited by kas1e on 2019/11/5 22:10:49
Edited by kas1e on 2019/11/5 22:46:49
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Just popping in


See User information
Ho Roman,

Is your code correct?
Fog_c : why use a sqrt on a squared number ( Sqrt of x*x)? And not x directly ? Or should it be something else?

Regards.

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
@Petrol
It is for sake of tests , to get rid of abs() (to be sure that is not abs() are buggy in Nova).

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
2) gl_FragColor=_gl4es_Fog.color;

all black so the fog color is not transmited = perhaps using a struct for fog params is wrong with Nova

So transmit fog params as basic uniforms in both frag & vertex shader

uniform vec4 Fog_color;
uniform float Fog_density;
uniform float Fog_start;
uniform float Fog_end;
uniform float Fog_scale;

Go to top

  Register To Post
« 1 ... 33 34 35 (36) 37 38 39 ... 42 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project