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.
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?
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.
@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.
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.
Do you have a smaller OpenGL example which uses succesfully glDrawArrays and GL_TRIANGLE_FANs?
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.
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).
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:
Check this context array creation/finding/expanding/shrinking routines in agl.c
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).
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Sam Lantinga
slouken@libsdl.org */
/*
* GL support for AmigaOS 4 using GL4ES->OGLES2
*/
void* aglGetProcAddress(const char *); // gl4es's aglGetProcAddress
void amiga_pre_swap(); // from gl4es to make working aglSwapBuffers()
void amiga_post_swap(); // from gl4es to make working aglSwapBuffers()
extern void initialize_gl4es(); // initialisation of gl4es.
int os4video_GL_LoadLibrary(_THIS, const char *path) {
/* Library is always open */
_this->gl_config.driver_loaded = 1;
return 0;
}
#endif
From gl4es side agl.c in no use, only amigaos.c , which for now looks like this:
#include "amigaos.h"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <proto/exec.h>
// make sure we don't use inline version here
#undef __USE_INLINE__
#include <proto/ogles2.h>
static void AmiglViewport (GLint x, GLint y, GLsizei width, GLsizei height) {
return IOGLES2->glViewport(x, y, width, height);
}
// Using glXXX name, return the function pointer of that function in ogles2 library
#define MAP(func_name, func) \
if (strcmp(name, func_name) == 0) return (void *)Ami##func;
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.
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):
I doubt he has checked any Amiga-specific code with Valgrind.
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.
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.
That asm is really hard to read for me. Do I see this correctly that tags are #defined (I don't have headers) to
OGLES2_CCT_WINDOW = 1
OGLES2_CCT_DEPTH = 3
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
#undef __USE_INLINE__
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.
See there in ogles2/ogles2_defs.h at top enum for tags.
Quote:
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().
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:
probably never gets called as the inlines likely map it to IOGLES2->aglCreateContext().
@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:
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
Normally tags need to be >= TAG_USER (0x80000000 + something). Does OGLES2 parse tags manually.
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.
I even can't understand what kind of bug it can be
Apart from mem trashes it could be things like compiler generating wrong code. Where sometimes it may not be even 100 % compiler fault, like with this strict aliasing stuff where it could be more a fault in the sources. Ever tried compiling with -O0 and or things like -fno-strict-aliasing? Maybe have once a gain a look at disassembled function which calls aglCreateContextTags() (the real function, not the dummy one, because it can be that correct code is generated for dummy one, but not real one which does more things incl. dprintf etc.).
Or it could be inside OGLES2's aglCreateContextTags() which must ~extract/~cast/~convert the "..." correctly to a struct TagItem* before passing it on to aglCreateContext(). On the various OSes/cpus and versions of it and it's compilers there are different methods (&lastparam +1, va_start() + co., va_startlinear() + co.,)
Please upload your minimal test examples (like Cadog stripped down) to my FTP. The less complex a test prog is the better.
Uploaded reports_here/cadog_test.lha. Inside 2 binaries, one with debugprintf before aglcreatecontexttags, and another without debugprinfs before aglcreatecontexttags.
There after running you can navigate to "exit" and exit from, all other stuff removed (most of it).
Run bins like this "bin_name -w - s 640x480". That one without debugprinfs before contexttags, should show background picture, another one, with debugprinfs before contexttags, show white background.
Through when you first time run "no debug printf" one, it also may not show background, but if you run it second time, it will (which all point on those random issues).
Quote:
Also note that the beforementioned fixed ogles2.lib 1.20 wip-version (also containing some other new features) is on the FTP too.
Yeah, will test it all now with all the games.
@Georg Quote:
Or it could be inside OGLES2's aglCreateContextTags() which must ~extract/~cast/~convert the "..." correctly to a struct TagItem* before passing it on to aglCreateContext(). On the various OSes/cpus and versions of it and it's compilers there are different methods (&lastparam +1, va_start() + co., va_startlinear() + co.,)
But then, pure aglCreateContext() should works fine. While with Cadog it is , memory trashing in LettersFall game still here.
But i will recheck with latest Daniel's ogles2.library with all those new createcontext functions, to see how it will behave now.
But i will recheck with latest Daniel's ogles2.library with all those new createcontext functions, to see how it will behave now.
It won't behave differently (well, if it does then it's just a sideeffect of sth. else) and it is certainly not the cause for any of our issues here. As being said: while Georg was of course absolutely right by pointing out the tags-wrong-IDs-bug in ogles2, there is nothing more there. And unless you used TAG_SKIP or other special tags (which AFAIK you did not), it simply did what you expected it to do. Other than this now fixed incompatibility to std. tags-processing, there is / was nothing wrong here. Don't forget to read the changelog.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
