SDL1 open issues

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

@kas1e

Which branch? I just checked the whole video in fix-listmodes and couldn't see dubious code like:

@Capehill
Quote:

Do all tests now on that commit: https://github.com/capehill/os4sdl/tre ... 6c610231922dc812980134ac6

But i probably found what issue is: that what i have in my gl4es addon, in the SDL_os4gl.c:



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.

Maybe you can briefly look at it, that what i do in SDL itself to make it work:
http://kas1e.mikendezign.com/aos4/gl4es/code/

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:

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

Maybe such mixing give some undefined behaviours in end..

@kas1e

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.

Where you have defined this OLDMINIGL?

@Capehill
Quote:

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:

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:

export ogl_render

ifeq ($(ogl_render, gl4es)
OGL_RENDER_CFLAGS = -DGL4ES
else
OGL_RENDER_CFLAGS = -DMINIGL
endif

(just in case, there is includes for gl4es which i have in SDK/local/common/include/GL4ES/): http://kas1e.mikendezign.com/aos4/gl4es/code/GL4ES_includes.zip

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:

Yep, commented that out, but didn't help in my case.

Quote:

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.

@Capehill
And check your paypal, just show that i apprecate all the work you do for sdl1 (and not only) and all your help with :)

@kas1e

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.

@Capehill
Ops sorry, wrong includes was uploaded (pure gles2 ones), there is gl4es ones: http://kas1e.mikendezign.com/aos4/gl4es/code/GL4ES_includes.zip

@Capehill
Quote:

Done, there is with my gl4es changes:
https://github.com/kas1e/SDL/tree/SDL-1.2gl4es/src/video/amigaos4

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

@kas1e

Have you tried to consult a local exorcist? Dunno. Stack? Race condition from outer space?

Sounds totally strange...

Thank you for the donation!

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

@kas1e+Capehill

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.

@Capehill (and TSK)

If you in interest , there is some more details about that issue: http://www.amigans.net/modules/xforum ... id=110202#forumpost110202

@kas1e

One obvious question: is IOGLES2 valid before creating the context?

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

@kas1e

If you call WaitTOF() in a loop, what FPS do you get? Might depend on your monitor icon INTERRUPT parameter?

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

@kas1e

Well I'm glad that VSYNC is now sorted out (could have never suspected a cable!).

Our Beret project has a primitive FPS counter, check the console. Try game with both HW and SW surface.

Beret seems "simple" but it uses fullscreen transparency so that is not trivial for slower CPUs...