Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
112 user(s) are online (65 user(s) are browsing Forums)

Members: 1
Guests: 111

trixie, more...

Headlines

 
  Register To Post  

« 1 ... 6 7 8 (9) 10 11 12 ... 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
@kas1e

Quote:
I not sure that guys who have 130 fps on the Radeon9250, have GART support. Did they ?:)

Yes, Radeon 9250s have GART support, and yes, it's used on other OSes.

Quote:
If, GART is soo much cool and nice, why amigans in last years all the time keep told that its software TCL which make problems with speed :)

Because software-TCL is a major bottleneck even if you refuse to believe us.

Quote:
Probably, if it _that_ nice and good , then instead of polaris drivers, having GART support in drivers we have , much much better course ?:) But its ritorical question :)

Supply of Southern Islands cards is drying up globally, which makes Polaris a high priority. We're well aware of GART's potential, and have more data to base priorities on than you...

Quote:
Yeah, and don't forget sky overlaping, z-fighting (or whatever, i just call it like this) when we watch in the mirror, and mess of textures in the letters fall (which can be side effect of that issues with gldrawlements). Also i found another bug, but will keep it for ourself, until Hans done with vertexattrib, as it can be side effect of it, as well.

I wonder if it really is z-fighting. We're using a 32-bit floating-point depth buffer and MiniGL has no issues using the same models, data, and graphics engine. So, depth-buffer precision is *not* an issue. Something weird seems to be going on. Is GL4ES converting data to a lower-precision format (which some mobile devices prefer) internally? In that case the GLES2 lib would have to convert it back. Such a two-step conversion could introduce errors (not to mention add unnecessary overhead).
Or, is it rescaling depth to better fit finite precision depth-buffers in a way that doesn't work well with a floating-point buffer?

There could be a bug at our end, but this issue is suspicious.


Quote:
Everyone keep saying and explain things, but result is : gl4es quake3 in glBegin/glEnd , with HARDWARE TCL, slower/the same as quake3 for minigl in glBegin/glEnd with SOFTWARE TCL. And that its after author of GL4ES make lots of optimisation (yeah, we all remember how we talk that Regaaaal ! Regalll will help us ! Which is slower than gl4es in 2 times :) )

I guess you missed my point in my earlier post: MiniGL's glBegin()/glEnd() pipeline is pretty decent; better than GL4ES' even with the new optimizations.

BSzili is right that Q3 has a low polygon count per mesh, so testing with something more demanding like OpenJK could deliver different results. And, heironymus profiling could tell more about where CPU time is being used up.

Either way, you need to take a big step back. You've done one test using archaic glBegin()/glEnd() and are then jumping to all sorts of conclusions that you don't have the data to make. Commercial games/apps stopped using glBegin()/glEnd() a long time ago for a reason...

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:

I wonder if it really is z-fighting. We're using a 32-bit floating-point depth buffer and MiniGL has no issues using the same models, data, and graphics engine. So, depth-buffer precision is *not* an issue. Something weird seems to be going on. Is GL4ES converting data to a lower-precision format (which some mobile devices prefer) internally? In that case the GLES2 lib would have to convert it back. Such a two-step conversion could introduce errors (not to mention add unnecessary overhead).
Or, is it rescaling depth to better fit finite precision depth-buffers in a way that doesn't work well with a floating-point buffer?


That what gl4es author say:

----
gl4es does as little conversion as possible. And it does no conversion for Depth Buffer. So if OGLES2 provide a 32bits float depth buffer, it will use it. But I'm not sure the artefact you have are really a precision problem, at least not the Sky issue. FYI, the sky is drawn very early in the frame, like 2nd or 3rd draw command IIRC.

As for mirror issues, I'll check later (tonight) on my capture if there is something special in the draw commands.
----


I checked that mirror-issue for another run, and now, i can see that there is just one diagonal line in the banner, not 2 as on another screenshot.

There is screenshot where i look on the mirror, and put head up, to the sky. See there all those triangles on the sky. Also there better visibly them on the walls too, in compare with first screenhot:

Resized Image


Edited by kas1e on 2018/3/5 9:28:25
Edited by kas1e on 2018/3/5 9:57:33
Edited by kas1e on 2018/3/5 10:05:31
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:
That what gl4es author say:

----
gl4es does as little conversion as possible. And it does no conversion for Depth Buffer. So if OGLES2 provide a 32bits float depth buffer, it will use it. But I'm not sure the artefact you have are really a precision problem, at least not the Sky issue. FYI, the sky is drawn very early in the frame, like 2nd or 3rd draw command IIRC.

As for mirror issues, I'll check later (tonight) on my capture if there is something special in the draw commands.
----


I meant conversion of the vertex data. Anyway, that still wouldn't explain why triangles that are supposed to be sharing vertices would end up with seams (which normally only occurs when vertices aren't exactly aligned). Your screenshot looks more like it's deliberately drawing lines at the edges (like the /r_showtris 1 option would, except r_showris renders the wireframe differently).

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
Not too shy to talk
Not too shy to talk


See User information
@Hans
I investigated. To make a long story short:

For whatever reason unknown to me it's an artefact by the mipmap filter, obviously only happening if Q3 renders its mirrors; the same geometry with the same texture parameters is rendered correctly if not going through the mirror.
If forcing the game to W3DN_LINEAR instead of a mipmap-filter, then the artefacts vanish.

I don't know how Q3 does its mirrors, apparently its neither render-to-texture nor via stencil, so it's probably done with some funny depth-buffer setup and / or via clip-planes (that latter would have to be implemented in some fancy gl4es shader), others will know better.

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
@Daytona675x, Hans
Quote:

or via clip-planes (that latter would have to be implemented in some fancy gl4es shader)


Yes, there is a clip plane when there is a mirror. The clipplane implementation is simple:

In the vertex shader, you will have a varying mediump vec4:
clippedvertex_0 = dot(vertex, _gl4es_ClipPlane_0);

(with _gl4es_ClipPlane_0 beeing a uniform highp vec4) and in the Fragment shader:

if(min(0., clippedvertex_0)<0.) discard;

Full vertex shader when we at mirror:

#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;
attribute highp vec4 _gl4es_MultiTexCoord0;
// FPE_Shader generated
// ** Vertex Shader **
// ligthting=0 (twosided=0, separate=0, color_material=0)
// secondary=0, planes=000001
// texture=00000001, point=0
varying vec4 Color;
uniform highp vec4 _gl4es_ClipPlane_0;
varying mediump float clippedvertex_0;
varying vec2 _gl4es_TexCoord_0;

void main() {
vec4 vertex _gl4es_ModelViewMatrix _gl4es_Vertex;
clippedvertex_0 dot(vertex_gl4es_ClipPlane_0);
gl_Position _gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
Color _gl4es_Color;
// texturing
// texture 0 active: 1  
_gl4es_TexCoord_0 _gl4es_MultiTexCoord0.xy;
}


Full fragment shader when we at mirror:

#version 100
precision mediump float;
precision mediump int;
// FPE_Shader generated
// ** Fragment Shader **
// lighting=0, alpha=0, secondary=0, planes=000001, texture=00000001, texformat=00000001 point=0
varying vec4 Color;
varying mediump float clippedvertex_0;
varying vec2 _gl4es_TexCoord_0;
uniform sampler2D _gl4es_TexSampler_0;
void main() {
if((
min(0.clippedvertex_0))<0.discard;
vec4 fColor Color;
vec4 texColor0 texture2D(_gl4es_TexSampler_0_gl4es_TexCoord_0);
// Texture 0 active: 1, texenv=0, format=1
fColor.rgb *= texColor0.rgb;
gl_FragColor fColor;
}



If anyone curious of why in the fragment shader he use min(0., clippedvertex_0)<0. instead of just clippedvertex_0<0. : it's because if there is more then one clipplane, he do min(0., clippedvertex_0)+min(0., clippedvertex_1)<0. to do only 1 "if".


Edited by kas1e on 2018/3/5 14:55:54
Edited by kas1e on 2018/3/5 15:09:44
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
@Daytona675x

Quote:
For whatever reason unknown to me it's an artefact by the mipmap filter, obviously only happening if Q3 renders its mirrors; the same geometry with the same texture parameters is rendered correctly if not going through the mirror.
If forcing the game to W3DN_LINEAR instead of a mipmap-filter, then the artefacts vanish.

Sounds like a driver bug. It looks like something I saw early on with anisotropic filtering.

@kas1e
Please submit a bug report for this, and send me a link to download the files I need to test 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
Yep, done few days ago

@Daniel
And probably we found at last what issues with q3/vertex_compiler are, sended all details via mail.

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

Just a curiosity, what version of Quake3 are you using for your gl4es test ?
There is somewhere an optimizated version from m3x/hunoppc .. it's a bit faster and maybe could be used for your test

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

Off-topic, but have you considered porting Raspberry PI version of Q3? It should be native OpenGL ES 2.0.

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
Yeah, why not. Through with that quake3 was mostly in interest to make GL4ES being bug free.

@Daniel
Dunno if you recieve my last mail about hack we add to the gl4es to fix those weird issues in quake3 with "Vertex Attribut of GL_UNSIGNED_BYTE that need Normalisation" , where i wrote that it also fix the same kind of issues as quake3 have, in IrrLicht engine (which is heavy enough, as well). And all the examples was broken before the same way as with quake3, but with hack all start works. Which can mean that its not undefined behaviour maybe ?

If it will be of any help, i can upload few irrlicht engine examples binaries with and without hack.


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
Just like the other ~100, I have received your mail, but since I covered pretty much everything in my previous mails answers and because I had other stuff to do, I didn't answer that one yet
I said before "the more the merrier", so no need to ask me, just upload your test builds on my FTP (btw. I never received your hacked q3), but:

Quote:
Vertex Attribut of GL_UNSIGNED_BYTE that need Normalisation

I already told you and will repeat it again once more:
This is definitely not the issue!
As being said I had already checked this out in depth before you did (simply because it was the very obvious difference in the other render path) and found it to be all good.

Quote:
And all the examples was broken before the same way as with quake3, but with hack all start works. Which can mean that its not undefined behaviour maybe ?

Let me repeat this one too:

"Don't draw false conclusions only because your hack seems to work around the problem. ...
The fact that some changes change that undefined behaviour doesn't conclude that those changes point directly at the true culprit, unfortunately."

The problem simply is not what you and the gl4es guy think it is. You are only changing the symptoms with your hacks.
Therefore, again a repetition: better revert that hack again, it was interesting but it turned out to not be the problem, so the only effect it has now is that it complicates things because it tends to "hide" the still existing real issue.

As with that ql4es build of that letter-game (which is broken for you but not for me) we simply got (semi)random / undefined behaviour here, caused by something else somewhere, but definitely not caused neither by glDrawElements nor the vertex-attribute's type / normalization.
Just let it go, man!

The root of the problem is somewhere else, earlier. It's most likely some memory coruption somewhere, where it is is still unknown, it can be in gl4es, it can be in ogles2, it can be in Nova (neither one can be ruled out yet).

As I told you I am investigating to make sure that it gets fixed - if it is an ogles2 issue. So far my investigations did not reveal a problem in ogles2, that's the current status. This does not mean that there is no problem in ogles2. It only means that I didn't find one yet. But I can say for sure that it is not directly related the vertex attributes being of type uint8 or normalized.

And also let me repeat something somebody else told you already: being pushy won't help

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

I don't think he's being pushy. I think he's just so excited to be making progress that he doesn't want to slow down. That's understandable given a platform where the progress has historically been measured in years....

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
@ferrels
Yes, I know that kas1e is very excited, which is good of course. And he's of great help. After all it's thanks to his efforts with first Regal and now gl4es that ogles2.lib and Nova are being tested in real-life rather intensenly now and already got some nice improvements / fixes in short time.

@kas1e
Sometimes I just have the feeling that you need to be grounded a bit
Step by step. We'll for sure find and fix that and any upcoming issues. Sometimes it simply takes more than a couple of hours

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
Dunno if you follow SDL1 thread , but if not, then i found some interesting issue, which very well related to memory trashing issues you mention.

So, while Capehill working on fixing and updating SDL1, i tried every new version with adding GL4ES to it. The way of how i do it from SDL1 side there:

https://github.com/kas1e/SDL/blob/SDL- ... ideo/amigaos4/SDL_os4gl.c

As you can see, there i only create context and passing all the stuff to SDL internal code (as MiniGL do before). I only create context there, because opening of ogles2 iface/library happens in GL4ES itself (he need it inside of gl4es), there:

https://github.com/ptitSeb/gl4es/blob/master/src/agl/amigaos.c

And there is helper functions, which named same as ogles2 ones, just calling without interface (so to have same names, but have some help code before running originals):

https://github.com/ptitSeb/gl4es/blob/master/src/agl/agl.c


Now, with SDL1 , i found that once i put before creating of context that "prinfs" line which you see in the first link, and build Cadog with it, then i have no background titile picture in game ! Just all white ! But once, i limit that string to only prinfs 1, or 2, or 3 bytes, then title picture is back. But only i printf 4 or more bytes, then its all fucks again.

Then, for sake of tests, i tryied to add in SDL1 for context creation not IOGLES2->aglCreateContextTags(), but IOGLES2->aglCreateContext() (and prepare structure TagList ourself). Then issues still here. But once i call it without IOGLES2, i.e. pure: hidden->IGL=aglCreateContext(0, tags); (so, to use helper function from gl4es, which basically do nothing at moment, but only call real OGLES2->aglCreateContext), then, title picture is back even with big prinfs !

Then, i also rebuild LettersFall with that new SDL1, where i swap IOGLES2->aglCreateContextTags() on aglCreateContext(), and that problems i have before _almost gone_ ! They still here, but they cleary change behaviour.

That all can mean again the same : memory trashing somewhere. And with those "prinfs" of few bytes before creatig of context, or with swapping way of how i create context , i only shift the memory trashing somewhere else (but not fix it of course, as , issues in LettersFall still there. Less,less visibly, but still there).

Sadly, but its again the same 3 parts in the combo: SDL1, Gl4ES and OGLES2/WARP3DNOVA, and i can't create any test case which will show memory trashing, and not involve anything from those 3 parts. Well, and in case with SDL, it also used a lot of 3d party libs (sdl_image, sdl_mixer, png, jpeg, etc ,etc) any of which can be memory-trashers as well, but with SDL1/MiniGL i never noticed such issues, so probably problem come from our usuall combo.

Now question is : how to detect where and what cause that.


Edited by kas1e on 2018/3/16 12:33:53
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 can't stay away
Just can't stay away


See User information
@kas1e

Here: https://github.com/kas1e/SDL/blob/SDL- ... /amigaos4/SDL_os4gl.c#L58

In the SDL code, do you want to call the wrapper function in gl4es or OGLES2 library function?


I didn't realize that there are similarly named wrapper functions (agl*) inside gl4es code. This could be the key. I don't know much about libraries but I checked AHX.library for a reference, and see how parameters are passed from varargs function:

APTR AHX_LoadTags(struct AHXPlayIFace *Self,
APTR buffer,
ULONG length,
...)
{
va_list ap;
struct TagItem *tags;

va_startlinear(ap, length);
tags = va_getlinearva(ap, struct TagItem *);

return Self->AHX_Load(
buffer,
length,
tags);
}

Maybe it also works if you modify the wrapper function to call the non-varargs wrapper function too:

va_list args;
va_start(args,errcode);
ret = aglCreateContextTags(errcode, args);
va_end(args);

Try running SDL_os4gl.c with "gcc -E" to see how the preprocessor output looks like.


Edited by Capehill on 2018/3/16 15:45:00
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
Quote:

In the SDL code, do you want to call the wrapper function in gl4es or OGLES2 library function?


I do not know how to do it better. Probably it should make no difference if it call them like OGLES2-> , or call them as helpers from agl.c (taken in account if they do nothing in helpers). All in all we have in agl.c "extern struct OGLES2IFace *IOGLES2; " , so it all should works by any way.

Before i just use pure OGLES2-> from SDL code, and where there was needs to add code from helpers (like for aglSwapBuffer), i just add them myself. Then i also tried to use all as helpers, and found that helper fucntion for aglCreateContextTags just do not works (i can see how SDL window creates and then closes immediately).

In repo we have it now like:

voidaglCreateContextTags(ULONG errcode, ...) {
    
voidret NULL;
    if(
IOGLES2) {
        
va_list args;
        
va_start(args,errcode);
        
ret IOGLES2->aglCreateContextTags(errcodeargs);
        
va_end(args);
    }
    return 
ret;
}


But, that didn't work. Probably because in ogles2 interface file, it is declared like this:

Quote:

void* VARARGS68K APICALL (*aglCreateContextTags)(struct OGLES2IFace *Self, ULONG * errcode, ...);



But anyway, even if didn't use helper's functions, but IOGLES2-> , then problem with Cadog still there. Just when i replace IOGLES2->aglCreateContextTags, on version without Tags, then problem with Cadog disappear, but that mean nothing, as issue with thashed memory still there, just shiftes.


Quote:

I didn't realize that there are similarly named wrapper functions (agl*) inside gl4es code. This could be the key.


Probably i need to ask him to rename them all, to something like gl4es_aglXXXX , etc to avoid misleading.

I do not know, is it possible that wrong writen helper for aglCreateContextTags (with all those varargs), can cause memory trashing, even, if it didn't used anywhere ? Probably no ? Sure on amigaos everything possible, but if i didn't call badly writen function, it should't trashing memory imho.

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

You cannot have a vararg wrapper function calling a vararg wrapped function (passing varargs from one to the other). That's not possible.

A wrapper function with vararg params only works if the wrapped function does *not* have vararg parms, ie. there is an alternative version of the wrapped function which instead of ..., takes for example a "va_list" param. Or a "struct TagItem *" param.

It may look like it sort of works (but things like adding variables, adding dprintfs() changes behaviour) but it really doesn't work. It just looks like that because the vararg params that were passed to wrapperfunction() are still there on the stack (and on PPC maybe partly in registers), so the wrapped function may pick them up, but incorrectly/half wrong/half right/completely wrong/not at all.

Try playing with this test program (try also on 68k, x86 if possible):

#include <stdio.h>
#include <stdarg.h>

void wrappedfunction(int a, ...)
{
    
int i;

    
va_list args;
    
va_start(argsa);
    
va_end(args);
    
    
printf("\nwrappedfunction:\n");
    for(
1<= 10i++)
    {
        
printf("  ARG %2d: %d\n"iva_arg(argsint));
    }
    
}

void wrapperfunction(int a, ...)
{
    
va_list args;
    
va_start(argsa);
    
wrappedfunction(aargs);
    
va_end(args);
}


void call_directly(void)
{
    
wrappedfunction(9999112233445566778899111222333);    
}

void call_wrapper(void)
{
    
wrapperfunction(9999112233445566778899111222333);    
}

int main(void)
{
    
call_directly();
    
call_wrapper();
}


OTOH you could make wrapper using macro: #define wrapperfunction(a, args...). That would work.

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

So since you seem to both have the non-vararg functions:

aglCreateContext()
OGLES2->aglCreateContext()

what your vararg wrapper function aglCreateContextTags(...) needs to do is to call one of those two (shouldn't matter which)) making sure to ~convert/~cast the "..." to a struct TagItem * in the correct way.

Either in same way as it is done elsewhere for similar wrappers (look in OS headers? VARARG68k, va_startlinear,whatever) or manually in similar way as GetTagsFromStack() in AROS source (compiler/alib/alib_util.c) which parses and clones the tags in va_list to new allocated memory.


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
Thanks for help !
Probably at this moment (for find the trashing memory issue),we will get rid of all those helper function all together, and use only OGLES2-> from SDL directly. But lately once we find the roots, we can deal with helpers too. thanks !

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
Now i just tried that:

1). didn't build gl4es's agl.c at all, so no helper functions will be compiled in/used, and use from SDL code everything with OGLES2->. So name clashing and problems with varargs ruled out at this point.

2). i build init.c of gl4es with -DNO_INIT_CONSTRUCTOR:
https://github.com/ptitSeb/gl4es/blob/master/src/gl/init.c

Quote:

#ifdef NO_INIT_CONSTRUCTOR
__attribute__((visibility("default")))
#else
__attribute__((constructor))
#endif


So to be able manually to call initialize_gl4es() from SDL code.

3). Now, creating of context from sdl looks like this:

int os4video_GL_Init(_THIS)
{

    
struct SDL_PrivateVideoData *hidden _this->hidden;
        
        
initialize_gl4es();
    
    
dprintf("Initializing GL4ES->OGLES2..\n");
    
    
hidden->IGL=IOGLES2->aglCreateContextTags(0,
                
OGLES2_CCT_WINDOW,(ULONG)hidden->win,
                
OGLES2_CCT_DEPTH,16,
                
OGLES2_CCT_STENCIL,8,
                
OGLES2_CCT_VSYNC,0,
                
OGLES2_CCT_SINGLE_GET_ERROR_MODE,1,
                
OGLES2_CCT_RESIZE_VIEWPORTTRUE,
            
TAG_DONE);


    if (
hidden->IGL)
    {
        
_this->gl_config.driver_loaded 1;
    
        
IOGLES2->aglMakeCurrent(hidden->IGL);
        
        
hidden->OpenGL TRUE;

        return 
0;
    }
    else
    {
        
_this->gl_config.driver_loaded 0;
        
SDL_SetError("Failed to create OGLES2 context");
    }

    return -
1;

}


So, once i compile it like this, Cadog have problem. Once i comment out "dprintf()" line : Cadog fine.

But, at this time i can't i can't reproduce it by pritnf("aaaa"); but that probably just because memory change the layout a bit when i build init.c with -DNO_INIT_CONSTRUCTOR.

Any ideas ?:)

At moment i think about starting to stripping of Cadog's code bit by bit , till will not have some very small test case. But that some hardcore , and possible once i will reduce size of Cadog (and its binary), issue will shifts too.

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

  Register To Post
« 1 ... 6 7 8 (9) 10 11 12 ... 42 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project