@Capehill As for that gl4es cadog's issue, something strange found : problems happens when we add debug switch to makefile. And problem is #define dprintf. Once it empty, like "#define dprintf(format, args...)" , then title pic show ups fine. But once i define it in any way (so just it be defined, and not empty), like for example "#define dprintf(format, args...) printf("aaaa\n"); , then no title pic visibly. Wtf it can be ?:)
See there dprintf("Initializing GL4ES->OGLES2..\n");
Once i comment it out, all works as before. That all can only mean something going bad with memory there, and probably not related to dprintf itself, but to the way how we add gl4es there :(
Maybe i just fuck SDL_PrivateVideoData in wrong way.
Just 4 files changed. SDL_os4_wrapper.c completely empty, SDL_os4gl.c new one , SDL_os4video.c and SDL_os4video.h have 2 changes (check for #ifdef OLDMINIGL). Probably, problem can be because of changes in SDL_PrivateVideoData structure, dunno.
All the "wrapping" code, and opening/closing of ogles2 library we do from gl4es itself. There is just 1 file for it:
I can't spot the issue. Have you done a clean build? (because dependencies are not tracked if you use the native makefile IIRC). Could you also send the git diff against whatever branch you are using, then it should be easier for you and me to compare changes.
One random thing is that if you are not using MiniGL, you probably don't want to call os4video_AllocateOpenGLBuffers ever, assuming OGLES2 is doing buffer management.
Have you done a clean build? (because dependencies are not tracked if you use the native makefile IIRC).
Yep, always done clean build. But as far as i see, with native makefile no dependencies creates at all, so if i only change pure .c file, then its enough to just rebuild that object and link new library. Its only if i change .h file, there need to whole rebuild imho.
Quote:
Could you also send the git diff against whatever branch you are using, then it should be easier for you and me to compare changes.
You mean diff git with those gl4es changes ? But as you see they hackish, as i completely remove minigl code from some files, but use the same .c files (so i do not need to worry about adding new files to the makefile, etc).
Maybe we need just another branch ("adding gl4es"), where we can put my changes, refactor it all a bit, etc ?
We can at moment just make it configurable in makefile. If let's say we do "make -f makefile.amigaos4 ogl_render=gl4es", then gl4es builds. If "make -f makefile.amigaos4 ogl_render=minigl" (or nothing, for example), then minigl build. Later we can think how to do it all better, etc, but for begining can be enough as well. Like this:
For public release then we can build with MiniGL, and any developer who want to use gl4es can buld sdl1 with gl4es switch ourself. Later we can think how to do it all better.. for now just having it in repo will solve extra hassle for sure :)
Quote:
One random thing is that if you are not using MiniGL, you probably don't want to call os4video_AllocateOpenGLBuffers ever, assuming OGLES2 is doing buffer management.
Yep, commented that out, but didn't help in my case.
Quote:
Where you have defined this OLDMINIGL?
I did't define it, its just like "#if 0" , so to have that part be commented out. It can be just #if 0, but i just call it like this so easy to view it all when do fast check of code.
Probably the easiest thing would be to fork https://github.com/AmigaPorts/SDL then add your gl4es changes in branch "SDL-1.2", or create a branch "SDL-1.2gl4es" based on "SDL-1.2" . Then it's possible do compare forks easily and you could pull updates from AmigaPorts/SDL and AmigaPorts/SDL could pull updates from you, even via web interface.
Or if you have the write access you can probably push a new branch directly to AmigaPorts.
Probably the easiest thing would be to fork https://github.com/AmigaPorts/SDL then add your gl4es changes in branch "SDL-1.2", or create a branch "SDL-1.2gl4es" based on "SDL-1.2" . Then it's possible do compare forks easily and you could pull updates from AmigaPorts/SDL and AmigaPorts/SDL could pull updates from you, even via web interface.
But they of course can't be used for merging, as it slash-and-hack..
So, with that version i have, when i build Cadog with that "dprintf" before context creation enabled : i didn't see title pic. But when i disable that "dprintf" line, i can see title pic and all fine and good. Before all was ok, just because dprinf doing nothing, but once we add -DDEBUG it start works, and then that issue come up.. Feels like some weird trashing of memory. Probably just some begining of image data overwriten by crap (in the memory, after loading done), and so as result there is nothing visibly. Strange through that it come up once dprintf line start working.
@Capehill Its even not necessary dprintf should be there. If i even put there pure printf("aaaa\n"); right before context creation, then i have no title pic in Cadog. Once i comment it out, title pic is back :)
I do some more tests, and found, that if i do :
printf("a\n"); or printf("aa\n"); or printf("aaa\n"); : title pic still here. But once i do more than 3 "aaa", i.e. even just printf("aaaa\n"); : then no title pic.
Which somehow prove my idea that in memory something overwriten by crap. Through now question is: how detect from where it come, from gl4es, from sdl or from cadog itself and how to deal with :)
@Capehill Maybe its because ogles2.library opened from libgl4es.a, but context created from sdl (and lately when i compile something i just do -lSDL -lgl4es) and something "not shared enough" ?
I may try enable munge on debug kernel, as well as add use of mungwall, maybe it will showup anything.
I've been fighting with random memory corruption with one of my software recently. (I'm suspecting that GCC doesn't handle multi dimensional arrays correctly still.) So anything is possible on AmigaOS.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
@Capehill Probably should, as if not , it should not create context / render to it at all imho. But i also use "helper" function from gl4es agl.c (just aglCreateContext, etc, without IOGLES2->), and in gl4es IOGLES2 are valid of course.
Btw, about tearing effect in doubl-buffering : i also checked "warp3d nova" example on my config, and it also have "tearing effect" !
@Capehill It was broken VGA cable on my end , which make DDC not working . Who can think that visually all looks ok, but cable still broken. That how it was for me with broken one:
See DDC area all nulls and empty.
Then i got today DVI-D cable, and once fireup os4 with it, then:
And everything start to works as expected, without tearing. Dbl-buffering example give 60fps, warp3d nova logo have no tearing effects too, and Beret with HWSURFACE works well too !
And should to say, that BERET even visually feel much more smooth now (expectually screen scroolling). Sadly we didn't not have FPS counter in the beret , but visually it just looks 2-3 time better.
@Capehill Also tried latest commit of fix-listmodes branch (where you add usage of LockBitMapTags instead of GetBitMapAttrs), and now it works even on graphics.library 54.226, which mean public graphics.library. Yeah !:)