GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

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

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

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

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

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



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.

@kas1e

Somewhere in the GLES4 source there were prototypes for the wrapper functions (using the identical names but without VARARGS68K APICALL). Have you ruled out them?

I would not blame Cadog yet. Or if you want to debug it, start with Valgrind and Clang sanitizer instead of diving in blindly.

@Capehill
Quote:

Yep, they all in the agl.c which i at moment didn't build, so libgl4es.a didn't have even that object with those wrapper functions.

@kas1e

Try

@Georg
Yeah, tried it yesterday : it did fix issue for Cadog, but still trashing of memory in another game (letters fall) still present. Its like it just once i use another function for context creation, issue with memory trashing shifts somewhere else.

Visually it look like this (press to open in new tab for fullsize images):





Of course it can be different issue, but as Cadog background disappear with depend on prinfs before context creation, i feel that trahing in the lettersfall game are of the same roots.

@kas1e

Do you have a smaller OpenGL example which uses succesfully glDrawArrays and GL_TRIANGLE_FANs? If you get consistently this drawing bug I think it's something else.

@Capehill
Quote:

Some small test cases works.

Tested 4 games so far:

Bloboats : have no problems

Cadog: have no problems, except that this disappeared title background pic if before context creation put some prinfs in the SDL code.

LettersFall : that trashing as show on screenhots above. But to add, Daniel on his setup didn't have that.

Quake3: works fine when it use glbegin/glend code path, but have bugs when use glDrawElements. From ogles2 side there is all ok as Daniel test. And it also seems like memory trahing issue. We made some workaround for it in gl4es , but it's just shift memory trashing somewhere else, but not actually fix anything.

IrrLicht Engine: have the same kind of problems as quake3 have (also use a lot of glDrawElements and glDrawArrays), and also by our workaround shift the trashing somewhere else.


We can think about some particular function being broken or so, but, example with Cadog (and the way how it reacts when there is just before printf ("aaa") or printfs ("aaaa") ; mean that there is 100% memory trahing issue.

I will try for now to remove all the opening of amiga stuff from gl4es, and doint 100% everything from SDL, to see if it will change anything.

@kas1e

Check this context array creation/finding/expanding/shrinking routines in agl.c. This in agl_context_remove() looks suspicious:



If an array contains len items then accessing array[len] is invalid. Even here where array is allocated/reallocated in chunks of multiple of 10 (agl_context_cap) and zeroed. Especially in case len happens to be multiple of 10, because then array[len] points to unallocated memory/chunk (not zeroed).

@Georg

It should be treated as false, and stop right there.
I think program is understand that if statement agl_context_len is 0 then first part of the statement is false, then there is no point for program and check if second part is also false, and requires bout to be TRUE.

Depending on agl_context_len being a index or the number of items. but i agree this make more sense:

while(agl_context_len && !agl_context[agl_context_len-1].context) agl_context_len--;

@Georg
Quote:
For now i even didn't use agl.c at all, and those agl_context_remove() in no use. I just open/close ogles2.library / iface from SDL, create context, and only after creating of context do call initialize_gl4es(); (so i do that to avoid any gl4es loading before context creation, in case its gl4es cause trashing at begining).

That how my SDL_os4gl.c currently looks like (which i link against libgl4es.a , without compiled agl.c in it).



From gl4es side agl.c in no use, only amigaos.c , which for now looks like this:



So, after that little reorganization, cadog issue with title pic, always there, and does not matter if i use dprintf or will just use some tiny 1 byte's pritnf("a"); (probably trashed memory shifts as i do open library / iface before context now).

But replacing IOGLES2->aglCreateContextTags() on IOGLES2->aglCreateContext(), make issue disappear (which again mean nothing , but only that issue with trashed memory shifts differently).

Now question is, WTF ! :) gl4es guy say that he offten check gl4es with Valgrind, so he sure there hould't be trashing coming from gl4es. SDL1 to blame ? But i remember i build quake3 without usage of SDL at all, just taken some pure MiniGL version and replaced it on GL4ES one, and have same issues as with SDL/MiniGL version.

@kas1e

I doubt he has checked any Amiga-specific code with Valgrind.

@kas1e

I would not rule out other kind of error (= not necessarily memory trash). Maybe the vararg function call simply goes wrong, like some header trouble causing VARARGS68K being defined to nothing and then the aglCreateContextTags() goes wrong, ie. it no longer pushes all args on the stack, instead some in registers, some on stack, like in a normal (non VARARGS68K) vararg call.

Look at generated compiler output (gcc -S). Add some dummy function which does the call and nothing else. So it's easier to read the asm (PPC asm is bad enough to read already):

@Capehill
Quote:
Sure he didn't, but he about Gl4ES, which he think can't be cause of memory trashing, as he check it with valgrind.

In other words, he mean that we can rule out gl4es itself from being guilty for memory trashing, and so we leave with SDL1 (+ my intergration of gl4es in), ogles2 and warp3dnova.

@Georg

There is output:



Should to add , that when i play with the settings of context, i.e., for example comment out OGLES2_CCT_STENCIL,8, and OGLES2_CCT_VSYNC,0, and made OGLES2_CCT_DEPTH not 16 , but 32, then background picture in Cadog back.

@kas1e

That asm is really hard to read for me. Do I see this correctly that tags are #defined (I don't have headers)
to



Normally tags need to be >= TAG_USER (0x80000000 + something). Does OGLES2 parse tags manually. Because otherwise there is conflict, because TAG_IGNORE = 3, and TAG_SKIP = 1, so such a taglist would be broken when used with normal tag parsing functions like NextTagItem().

I noticed



Does other OGLES test programs/demos/games/whatever work if they do this too and they are at the same time using vararg functions like aglCreateContextTags(). Because when USE_INLINE is active the IOGLES2->aglCreateContextTags() probably never gets called as the inlines likely map it to IOGLES2->aglCreateContext().

So it could be that IOGLES2->aglCreateContextTags() itself is broken inside IOGLES2.

@Georg
There is ogles2 includes: http://kas1e.mikendezign.com/aos4/gl4es/gles2_os4_includes.zip

See there in ogles2/ogles2_defs.h at top enum for tags.

Quote:

Never tried to be honest.

But , still, that we talk about Cadog issue only, while, if i just use pure aglCreateContext() (without Tags at end). This fix issue with Cadog, but didn't fix issues with trashed textures in the LettersFall game.

That of course can be just 2 different issues, through..

Quote:

At least in inlines of ogles2, i see that :

Quote:

@Georg
After checking more about: #undef __USE_INLINE__ used only in gl4es's amigaos.c / agl.c files, just so he sure that we don't use inline version here (he do so before when he use wrapper functinos with the same names, so to avoid conflicts just in case).

Now i don't use agl.c , only amigaos.c , and as it part of GL4ES, it builds separately from SDL (from where i do context creation), it builds when i build libgl4es.a. What mean, that it can't be related, as well as gcc -S on SDL file where i create ogles2 context, will show nothing wrong , as undef is only for amigaos.c which is in libgl4es.a.

At moment i trying to short as possible Cadog game by cutting off all the game's code , so to just keep loading of texture and showing menu. At moment cut off levels, music/sound loading (so on linking stage no more links with music/sound libs), and bug still there. Hope to reduce it to very minimum and bug still will be there, then it will be much easer to find out what wrong.

Was able to cut off from cadog as much as possible, i.e. pure loading of necessary stuff and ability to choice exit from. No music, no sounds, no leveles, no game, just first title pic, and ability to choice exit from game.

Now, when i step by step reduce code of game, bug was the same always : i.e. i just replace aglCreateContextTags() with aglCreateContext() and all works. Then, at some point when i remove quite a lot, background picture was ok in both cases, and with aglCreateContextTags(), and with aglCreateContext(), but then, i add some "printf" before aglCreateContextTags(), and bug appears again. Once a put aglCreateContext() in use, with the same printf, then all fine.

And in code which keept at moment in Cadog, even no single glDraw... function is used. Just some crap like:

glBegin(GL_QUADS);
glTexCoord2f(0,0); glVertex3f(x,y,z);
glEnd;

and co.


Dunno where to look next. Maybe trying to get rid of SDL and open ogles2 / create context / initialize gl4es from game's code itself, but then if bug will just disappear, and can't be triggered again that will mean nothing. As it now at least it reproducable (sort of).

I even can't understand what kind of bug it can be, as it all looks like depends of how big/small sections of code/data, and how they shifted, or how and where data placed. Like not like just usuall memmory trashing

@Georg
Quote:
Nice great stupidity by me indeed
But yes, I do parse those manually so as long as you only use the tags that are defined by ogles2.lib everything is good (and if you don't "comply" here then the context will not be created as you configured it (or maybe in worst case simply crash there), no matter if you use the vararg or the struct-ptr variant, which internally boil down to execute the same code). I just fixed it for the next lib release. Thanks for noting!

@kas1e
Please upload your minimal test examples (like Cadog stripped down) to my FTP. The less complex a test prog is the better.
Also note that the beforementioned fixed ogles2.lib 1.20 wip-version (also containing some other new features) is on the FTP too.