@CapehillAs 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 ?:)

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.

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.

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

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

@CapehillAlso 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 !:)