Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
71 user(s) are online (50 user(s) are browsing Forums)

Members: 1
Guests: 70

smf, more...

Headlines

 
  Register To Post  

« 1 ... 10 11 12 (13) 14 15 16 ... 42 »
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Just popping in


See User information
@kas1e

You have got pointers in this index array!

fpe_glDrawElements(GL_TRIANGLES54GL_UNSIGNED_SHORT0x69378e50), program=0
creating FPE shader 
264(0x68f1bd18)
Use 
FPE program 264
glVertexAttribPointer
(04GL_FLOAT000x6a3258f0)
glVertexAttribPointer(14GL_FLOAT000x6a3254e8)
Indices=26935 36424,26935,36424,0,0,6,7,8,8,7,9,8,9,10,10,9,11,10,11,12,12,11,13,12,13,14,14,13,15,14,15,16,16,15,17,16,17,18,18,17,19,18,19,20,20,19,21,20,21,22,22,21,23,
There are 54 indicesmax value is 36424


26935 == hex 0x6937
36424 == hex 0x8e48

-> 0x69378e48

kinda close to pointer passed to glDrawElements(), isn't it?


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
In neverball log:

indeces 43949,51966 -> 0xABADCAFE


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
@Georg
Probably 0xabadcafe flying there as i on debug kernel + munge enabled in. Anyway that all looks quite strange, like some stack-data--pointer overflow

In meantime will try to print out indicies in lettersfall game (which works, but have trashing), maybe its all about one problem in end.

edit: lettersfall use glDrawArrays only, and there no indicies to print. Anyway probably only roots of problems in neverball will be found, will be clear how to deal with all others problems (probably).

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

In gl.c/glDrawElementsCommon() try to change the two places which use gl4es_scratch() to instead alloc tmp memory in another way:

static void glDrawElementsCommon
{
   
void *tmp_scratch NULL;

[..]
   
//gl4es_scratch(..)
   // GLuint *tmp = ...

   
GLuint *tmp malloc(ilen*sizeof(GLuint);
[..]
   
//gl4es_scratch()
   // GLushort *tmp = ...
   
GLushort *tmp malloc(ilen*sizeof(GLushort);
[..]
   if (
tmp_scratchfree(tmp_scratch)
}


Maybe the code later on somewhere by mistake uses gl4es_scratch() in a nested way (reuse scratch, while scratch is already in use by this place here).

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
@Georg
Tried: didn't make differences.

But what we also tried, its to add to gl.c , at line 1065 the line if(indices && indices[0]>0x2000) printf("Too late...\n");
And, before crash we have that "too late" thing, which dunno, somehow point on race condition maybe ?

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
Issue with neverball/neverputt was because of gl4es: it crashes even on other platforms (damn). So gl4es guy fix it:
"Fixed a nasty bug when merging drawlist inside a glList and no indices were present".

https://github.com/ptitSeb/gl4es/commi ... bfdb60d4d649e3964708c6455

Now neverball and neverputt both runs fine. And, by FPS it is faster in 2-3 times than minigl version. For example first stage in neverball, in minigl version give 58 fps, in gl4es one give 150fps. In some other hardcore by details level, minigl version give 9fps, gl4es one - 22fps. Dunno why there is faster (in compare with let's say, quake3), as both games use glBegin/glEnd route. But code different anyway, so eveyrthing possible.

Also in MiniGL version in both neverball and neverputt , there is sometime visuall glitchs and "blinks", while in gl4es version on the same places , all renders correctly.


He also for sake of remove from list.c arrays on stack:
https://github.com/ptitSeb/gl4es/commi ... 32eff82b6310f95018b242251

But in end, not fix for neverball, not removing arrays from stack make no fixes for cadog test case and letter's fall textures trashing in menu, sadly :(



Edited by kas1e on 2018/3/27 11:04:35
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
@Georg
Quote:
In neverball log: indeces 43949,51966 -> 0xABADCAFE

LOL

@kas1e
Quote:
Issue with neverball/neverputt was because of gl4es: it crashes even on other platforms (damn). So gl4es guy fix it

Great! But why "damn"?

Quote:
Now neverball and neverputt both runs fine. And, by FPS it is faster in 2-3 times than minigl version.

Aha!

Quote:
Dunno why there is faster (in compare with let's say, quake3), as both games use glBegin/glEnd route.

Maybe neverXXXX uses display-lists which probably results in a less inefficient render-path inside gl4es (or maybe he even uses VBOs then?).
Did it also fix Q3?

Quote:
He also for sake of remove from list.c arrays on stack:

I don't think this is wise. The stack-allocated index array shouldn't be an issue by itself (unless the stack is too small of course, but I suppose we can rule that out) and it's much faster than the fastest malloc.
This is the typical "a crash symptom appeared at XYZ, so let's change XYZ"-tactic he should definitely avoid!
So unless he found a true bug there, he should better revert it.


Edited by Daytona675x on 2018/3/27 11:55:47
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:

Great! But why "damn"?


I was in hope that its all about probems and with cadog test case, and with letters fall trashing, and with quake3 / irrlicht, but as it didn't help anywhere, but only in neverball/neverputt, then damn, as it mean again we on the same point as 2 weeks ago called "we do not know where to find roots".

Quote:

Did it also fix Q3?


He say this issue was very specific: you need to have glList for it to trigger. Other games doesn't used them probably, so it will not fix our issues.

But i anyway do test it of course, and nope, all the same as we have before. But with neverball/neverputt he reproduce it on his side, so it was easy, while other issues he can't reproduce.

In other words we again on the same place called random-unknown-shit :)



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
Btw, did you checked irrlicht example ? There is also 2 verions hacked and non hacked, and issues are the same as in quake3. Maybe it will give some more info in compare with just q3 ?

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
@kas1e
Next test GL4ES ... SuperTuxKart ?

http://www.supertuxkart-amiga.de/amigaos.html

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

Quote:

Probably 0xabadcafe flying there as i on debug kernel + munge enabled in.


Btw, in case the clib uses it's own special routines for malloc + co. (instead of just Exec memory/pool functions) then mungwall like memory tool may not be able to track each and every single malloc'ed memory.

This may hide errors which such tools can detect, so sometimes for debugging things it helps to temporarily have in your code your own very simple implementation for malloc/calloc/realloc/free which simply map to AllocVec,FreeVec(),CopyMem(). Just put your replacement function somewhere in the source and that should be enough to cause the clib ones to be overriden (at least with static clib).




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

Can you just write Validator, that check if the content of the table is correct, and report where it gets broken with printf() and pause it with getchar();

gl_...(...)
validate(__FUNCTION__,__LINE__,...)
gl_...(...)
validate(__FUNCTION__,__LINE__,...)
gl_...(...)
validate(__FUNCTION__,__LINE__,...)

etc.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
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
@Georg
I build all with newlib, but yes, you are right that not all mungwall tools works the same. For example munge functionality of debug kernel do not catch everything, not from clib2, not from newlib. While when you add memguard at top, it can catch much more and not only from clib2 ones, but from newlib ones as well (which is strange, as menguard kind of dated). Through currently cant use memguard on x5k, as it hits a lot to some system component, so until that fixed cant use it.


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
Some report so to show it not forgotten:

1). We found some issue in the shader related code in NOVA (false assign of some alpha components to wrong values): http://amigadeveloper.com/bugreports/view.php?id=318
But, even if it will be fixed, that probably not related to the trashing issues in letters fall, that strange issues in cadog-cutoff-test, and with issues with quake3 & irrlich engine.

2). Now as i can do nothing more about, i will setup some ppc linux on my x5k, compile some glES emulator (software mesa one probabaly), and will check gl4es on linux. By that we can (or can't) rule out issues with big endianes. If any of issues we have on os4 now will be on linux too: then gl4es need more ppc fixes , if not, then it will mean our side (nova, ogles, sdl, my dirty hands or whatever else).

3). We also can wait till nova will have support of arrays in the shaders, then, i may try to use Regal too, to see, if it will possibe to compile the same games , and if they will or will not behave the same as gl4es in term of bugs. But that of course "if", as it needs nova-with-arrays , and no one can be sure that Regal is matured enough to run those games we run over gl4es.

At this moment that all about what i can think of.

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
Some news: Hans fixed issue with q3 when we look at mirror , as well as added OpSelect to shaders (so, more stuff works over gl4es with it).

@Hans
Btw, if you do check quake3 test archive, you may notice that once we walk to any place of any level where we have sky, then the sky is overlap some parts of levels's textures.

I made short video to show issue (sorry for low phone quality):

https://youtu.be/D2Scoj65ezA

I show that video to gl4es author and reask if he didn't have that issues with gl4es on his platforms, and he say that all good on his side and it looks like some precision issue with the Depth buffer. Also he say that quake3 render sky first thing, than the other stuff are renderer on top of it. The sky is supposed to be far away, so maybe there is some loss of precision in the depth buffer with the sky values.

He also point out where all the Sky function in quake3 and the actual drawing and so i can from my side add some printf (of s_skyPoints[t][s]) to see what kind of coordinates are used for the sky, which may help finding the issue.

Should i create BZ about as well ?

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

Really cool to see progress on this..

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
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:
Btw, if you do check quake3 test archive, you may notice that once we walk to any place of any level where we have sky, then the sky is overlap some parts of levels's textures.

I made short video to show issue (sorry for low phone quality):

https://youtu.be/D2Scoj65ezA

I show that video to gl4es author and reask if he didn't have that issues with gl4es on his platforms, and he say that all good on his side and it looks like some precision issue with the Depth buffer. Also he say that quake3 render sky first thing, than the other stuff are renderer on top of it. The sky is supposed to be far away, so maybe there is some loss of precision in the depth buffer with the sky values.


To me it looks like there's a clipping plane set that shouldn't be there, or the skybox is somehow not rendered in the right place. Or, is the depth-buffer mistakenly left enabled when rendering the skybox?** No idea how the Q3 code works but, when a skybox is rendered first it makes sense to disable the depth buffer entirely because the skybox is supposed to be infinitely far away (i.e., all pixels remain at the zfar value you cleared it to).

Quote:
Should i create BZ about as well ?

Please spend a bit more time looking for the root cause first. Especially check whether the skybox rendering code is disabling the depth buffer (in which case we need to check whether that's actually happening).

It does NOT look like a depth-buffer precision issue to me.

Hans


** NOTE: There are two states controlling whether the depth-buffer is enabled:
- Enable/disable depth testing
- Enable/disable writing to the depth-buffer
I expect that writing to the depth-buffer should be disabled when rendering the skybox... unless rendering the skybox is used to clear the depth buffer (in which case depth testing will be disabled or set to "always")

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:

Please spend a bit more time looking for the root cause first. Especially check whether the skybox rendering code is disabling the depth buffer (in which case we need to check whether that's actually happening).


Seems we (mostly gl4es guy of course, i only do tests on my side when follow his suggestions) found roots.

Short story: OGLES2 or W3DNOVA doesn't like to have a depth range that is not a range.

Long story: Rendering of Sky in the Q3 happens in the file code/renderergl1/tr_sky.c. There is relevant part of code:

/*
================
RB_StageIteratorSky

All of the visible sky triangles are in tess

Other things could be stuck in here, like birds in the sky, etc
================
*/
void RB_StageIteratorSkyvoid ) {
    if ( 
r_fastsky->integer ) {
        return;
    }

    
// go through all the polygons and project them onto
    // the sky box to see which blocks on each side need
    // to be drawn
    
RB_ClipSkyPolygons( &tess );

    
// r_showsky will let all the sky blocks be drawn in
    // front of everything to allow developers to see how
    // much sky is getting sucked in
    
if ( r_showsky->integer ) {
        
qglDepthRange0.00.0 );
    } else {
        
qglDepthRange1.01.0 );
    }

    
// draw the outer skybox
    
if ( tess.shader->sky.outerbox[0] && tess.shader->sky.outerbox[0] != tr.defaultImage ) {
        
qglColor3ftr.identityLighttr.identityLighttr.identityLight );
        
        
qglPushMatrix ();
        
GL_State);
        
qglTranslatef (backEnd.viewParms.or.origin[0], backEnd.viewParms.or.origin[1], backEnd.viewParms.or.origin[2]);

        
DrawSkyBoxtess.shader );

        
qglPopMatrix();
    }

    
// generate the vertexes for all the clouds, which will be drawn
    // by the generic shader routine
    
R_BuildCloudData( &tess );

    
RB_StageIteratorGeneric();

    
// draw the inner skybox


    // back to normal depth range
    
qglDepthRange0.01.0 );

    
// note that sky was drawn so we will draw a sun later
    
backEnd.skyRenderedThisView qtrue;
}


As you can see at top of function, there is qglDepthRange( 1.0, 1.0 ); call, which is not "range" as it, but still should work anyway. Once we replace it to be some kind of range, i.e. on qglDepthRange( 0.9, 1.0 );, then everything works as expected.

Then, to be 100% sure that it is issue with "range not range", we change it on 0.9, 0.9, and it again broken.

So, that mean that ogles2 or nova doesn't like when glDepthRange range is not range.

ps. qglDepthRange it just define to glDepthRange.

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:
So, that mean that ogles2 or nova doesn't like when glDepthRange range is not range.

EDIT: I've just checked, and Warp3DNova's SetViewport() is never called by Q3 with a z range of [1.0, 1.0]. So, the problem lies further upstream...

EDIT2: Wrong! On closer inspection SetViewport() was rejecting zNear == zFar as illegal. It'll be fixed in the next version.

Hans


Edited by Hans on 2018/5/2 10:10:48
Edited by Hans on 2018/5/2 10:45:22
Edited by Hans on 2018/5/2 12:35:46
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
Thanks! No needs for BZ then ?

Will try today to check neverballs shader about which you ask on BZ. But first tests show that setting color.a = 1.0; make alpha works too.

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

  Register To Post
« 1 ... 10 11 12 (13) 14 15 16 ... 42 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project