@Capehill
So, tested with all things back (set title and stuff), and with UpdateTexture() seems deadlocks are gone. I can't say for 100% sure right now, but I test it for a few hours and seems didn't have it.

At moment found some other little issue which can be again dosbox of course.. When i run dosbox with "output=texture", and dosbox are active already (window for sure), then to have good speed back as in case with "output=surface", i need to click on workbench so make it active, and then click again on dosbox to make it active, then speed is back.

(and then, even with opengles2 renderer speed is more or less the same, so i assume with opengl it will be more or less the same too once that "what screen" thing can be done).

Btw, is SDL2 branch "fix ogles2 renderer" mean to fix that "blue" colors ? I mean i can probabaly use it for dosbox at least if it is.

@kas1e

Without lock DB cannot cause dead-lock :)

Do you mean that when DB window is not active, it will get slower?

Cause is probably this: https://github.com/dreamer/dosbox-stag ... src/gui/sdlmain.cpp#L2015

Regarding OGLES2, you can try that. Render targets are still broken and I just haven't had time to debug those, but I think DB doesn't use render targets (FBOs).

@Capehill
Quote:

No, DB is active when i run it, but like "not fully active", i need to click on wb screen and back on DB to gain speed i have with output=surface by default.

Quote:

Hm, with "surface" output didn't have that issue, only with "texture". As events the same for all outputs, it probabaly should be same for all (just guess, of course).

Quote:

Yeah good, will try then too.

EDIT: you were right as usuall, commenting out CPU_Enable_SkipAutoAdjust() make it works from begining. Drawback is that when i hit WB now, speed didn't drops as should, but that all probabaly mean that on running with "output=texture" we by some reassons loose focus, while with "output=surface" we not.

@kas1e

So it seems that window events should be compared between texture / surface modes, just in case there is some difference.

@Capehill
I just put prinfs() to SDL_WINDOWEVENT_FOCUS_LOST:, and confirmed that when we have output=surface then we have no prinfs from, but when output=texture, we have printf from and focus lost.

So need to compare wtf. Strangely that in their GUI_StartUp(), there is:

SetPriority(sdl.priority.focus); //Assume focus on startup

Kind of like should be done for everything, but then later it lost for texture output only.


EDIT: and yes, "ogles2 fix" branch works for dosbox! No more blue colors. And speed are the same as with compositing renderer, not worse for sure. Just when first frames are draws, it always show some old garbage, like memory wasn't clear via glclear or something. But that jus first frame, after all fine.

So, only to fix that damn opengl white-screen. Have maybe any ideas what/where to prinfs/debug/etc. As it works for ogles2, there for sure should be something not _that_ hardcore. I surely see first frame, it clears by white after. Like wrong gl_Swapbuffer or something.


EDIT2: I do compile win32 version of dosbox-staging, and there is the same focus lost when we use "output=texture", and didn't when we use "output=surface". So that not our fault which is good! Reported to them.

@Capehill
Made an archive of DOSBox in a shared version, compiled with a replacement for lock/unlock on update texture, and with OpenGL fixes (so to not crash on exit).

http://kas1e.mikendezign.com/aos4/dos ... x_shared_ogl_renderer.lha

There already setuped in config "output=texture" and "texture_renderer=opengl", just unpack and run and will see white screen (close button works, so no freezes, you even can type things in dosbox, just can't see it). Other possible values for "texture_renderer": software, compositing, opengles2 - all works, but the white screen is OpenGL renderer only issue. Through you can see how frames visibly before it goes white.

I assume we can't print anything from DOSBox there, as its "renderer" code of SDL2, so probably we need to catch GL_Errors or something not from DosBox but from SDL2's OpenGL renderer's code?

That the output i have on serial when run with "texture_renderer=opengl":



Also checked src/render/opengl/SDL_render_gl.c, i see there is GL_CheckError is used, but as we have nothing on serial, it seems like "all ok" in terms of gl_error ?

Through in output i can see that we have 2 failing calls:

[OS4_GL_GetProcAddress] Failed to load 'glBlendEquation'
and
[OS4_GL_GetProcAddress] Failed to load 'glBlendFuncSeparate'

Can it be related?

Or maybe that glActiveTextureARB at end can be the cause ? (at least as if i can see the first frames before, and all go to white mode at end, so it can be it?)

@kas1e

Maybe glBlendEquation is not supported in our current minigl

I found an old but interesting thread that show a similar problem you have

http://www.amigaworld.net/modules/new ... opic_id=33530&forum=43&12

And:

https://github.com/AmigaPorts/SDL/pull ... 4bd6dd16593b76c3f4d776b56

@samo79

Nope, its not the cause of white screen : I compile GL4ES version of dosbox as well, and it give me the same white screen, but, this time output is fine and all functions found:



But of course, that didn't mean that it can't be something in SDL as well, maybe something was done back in past / now about those functions, so even for gl4es build they a bit in some changed state (i do not remember i touch anything about for gl4es, so if they changed, they probabaly changed for gl4es too).

@kas1e

Maybe you can run GL4ES version with glSnoop?

@Capehill
Good idea!

There is when i run it with texture_renderer=opengl:

http://kas1e.mikendezign.com/aos4/dos ... n_gl4es_glsnoop_trace.txt

First frame shows fine, and when those repeat-blocks go:

Quote:

Its already white. That what come before those blocks, made the first rendered frame be visibly, and then white-screen time for each frame.

For sake of interest, i also capture NOVA only, maybe it will give us some more ideas. There is only relevant part:

When frame start to be shown (visibly fine), and then when repeat blocks coming its all white already:

http://kas1e.mikendezign.com/aos4/dos ... r/nova_relevant_trace.txt

EDIT: All i can see there, that there 2 glClearColor calls, one with

red 1.000000, green 1.000000, blue 1.000000, alpha 1.000000

and another ones with

red 0.000000, green 0.000000, blue 0.000000, alpha 1.000000

Not sure if it related of course.

@Capehill

It seems MBeijer start integrating OS3 code into the official OS4 repo :)
He also added some OS4 code to finally compile SDL1 as shared library ... would be interesting to see if everything will works already !

https://github.com/AmigaPorts/SDL/comm ... ab1ede3ab5d15814199eda87f

If so, perhaps the same could be done also in SDL2 for compile it as shared :)

@samo79

I think it means ".so" (shared object) rather than ".library".

To be honest I'm not sure how to even implement SDL as a shared library for AmigaOS 4. It would need to be API-compatible with the original SDL, otherwise there wouldn't be any sense in it as the point of SDL is portability.

@samo79, Capehill
And making sdl.library for amigaos4 it is waste of valuable time: we already have .so for those who want it be "shared", and static builds.

And i hope nothing will be broken with all that new injection of new code for our os4 builds at least, and code which Capehill carefully did for few years and we spend lot of time on testing every single issue will be not changed. Even single few replacements of letters can cause new issues which we will not know for long. Touching all that without proper testing and stuff it's just too much.

@Capehill
Maybe it worth to take last code which was before new changes from MBeijer and made an official SDL1 os4 release ? At least with that code i am sure all fine, but what happens next i even do not want to test and spend time on.

There are many changes was done in just single commit, and no one can say that everything correct or not and if anything broke our builds or change things somewhere. At least i see there was mistakes like removing opengl support for os4 build, and broken os4 makefile, etc, while that should't be touched at all. Why there needs to change our builds and os4 files ? we loose too much time on it, to just made it all be changed that fast in such a massive commits.

For example, we don't need there CMake support that for sure. Not everyone use cross-compiler, and we don't have decent enough native CMake port. We are fine with makefiles already. They faster and simpler, no needs for CMake. There was some changes in our makefile too, wtf, why it touched at all ?

There even touched some general SDL files too, like adding to some .h externs of execbase, which we on os4 do not need, and it may give us warning (or even errors).

Or like paths to includes was changed in some places in test files. SDL_config_amiga.h was changed, etc.

In other words some massive reorganization of all things start to happend. Surelu i as tester not have motivation to dig in again in the same what was past done..


Maybe it even worth to fork of what we have done before before his changes starts to your github ? I just fear there can be new changes, which we just don't need. And i for sure don't have energy and motivation to retest everything again and again, on which we spend that much time already. You anyway only one working on this, and I with Raziel only ones testing it. So be it in any other repo will not change things for us.

Lately if there will be wish it all can be merged to whatever anyone want, but not like it now when that much work done, and there in one push "hey hey ! let's add some more stuff ! its all will be WIP which need testing and re-testing now!" without asking what we need and if we need all or some of changes.

@Capehill

No it meant shared library for sure .. but using shared does not means we be forced to lose API compatibilty ... will be exactly how it always was in other Amiga like system (os3, morphos)

@kas1e

Yeah, i fell your fear :)
but don't worry github have all the means to revert eventual bad changes if needed

@samo
Capehill know what he say :) If he say it can't be done easy, then it is :) No one exept him will do so. And even and if anything writen in any commit with only simple changes in cmakefile.txt, didn't mean things start to magically happens. Its just about .so, not about .library. Its about Cmake support, and in this commit was added support to build shared (in terms of linux) version, which mean ".so" via Cmake, which we already do well with pure makefiles.

Quote:

No, will not. OS4 libraries code are very different to os3/morphos one. If you remember back in past to make 68k libraries works, we need to create special "glue" .l.main files to make it work. And that not only one problems. Its not what you think in other words. You also can trust me, i loose lots of time with dopus5 and all those os3/os4/mos/aros libraries. Its all different and hardcore.

@kas1e

Quote:

This looked like a promising clue but I cannot see SDL_renderer binding default texture ever so I suspect it comes from either GL4ES or there is a stray glBindTexture call in DosBox. Of course one could also use a debug MiniGL build but there is only so much free time in a day.

I didn't catch GL errors either when trying to debug SDL_Renderer.

Can you disable OpenGL when building DosBox, just to rule out that it doesn't interfere with SDL's OpenGL state in any way? I know it's a desperate but probably you have to only rebuild the file with SDL code.

@Capehill
Quote:

But its the same for MiniGL as well. So something wrong for both, and for MiniGL and for GL4ES then (but probabaly its DosBox instead:) ).

Quote:

I surely can do so, but what to debug there?


Quote:

Will try now, few mins.

@kas1e

Let's not worry too much about SDL merge. I hope to review the changes and maybe test it during weekend or whenever there is some free time.

Regarding theoretical .library: I guess it would be nice, "Amigaish", but developing it is certainly not a priority for me. But honestly, can you see somebody doing ISDL2->SDL_Init()?

With git repo we are not going to lose anything so there is no real fear.

Quote:

glBindTexture parameters at least.

@Capehill
Quote:

Of course not. And no one will do. That why i dislike always morphos's native libraries of all those opensource libs such as png, jpg, sdl and stuff : You not just port things, but you do borrrring work to add "specific" stuff. With os4 it will be even harder without __USE_INLINE__ with all that ISDL->, but porting with or without will be then harder for nothing : you will need to add boring and non-intersting specific code, like opening library and stuff. Using of "native" functions, which done only to support what can be done without those native functions :) Naah..

So yeah, that one for sure not need it.

@Capehill
Disabled opengl (so when i use output=opengl, i have "sorry no opengl output, switch back to compositing"), and then output=texture + texture_renderer=opengl => white screen :)

But for output=texture + texture_renderer=opengles2 , no white screen.

That why i think about SDL2's GL renderer issue there : if it was let's say minigl and gl4es, then with ogles2 renderer i should have same white screen , but as with ogles2 renderer i didn't have white screen, but have with gl4es (which is replacement for minigl code in SDL), that mean that its opengl code in SDL can be guilty ? (i hope at least).

I may give a better test on win32 side as well. It works of course there, but i will now double-triple retest.

EDIT: on win32 surely works :( no white screen.