SDL2

@kas1e

Sometimes it would be simpler to let the code do talking. Out of curiosity, are you using this source (SDL2):

https://github.com/dreamer/dosbox-staging

Does it compile on OS4 native?

And is jmarsh fellow using SDL1 and is his SDL port here: https://github.com/dborth/sdl-wii

@Capehill
Btw, I read somewhere that for 2.0.10 release (our last official one was 2.0.9), they made batched rendering be used by SDL's rendering API by default. I not sure if it mean that they have "1" for batching by default now and if so do we, or should we ? In general, if it didn't bring any shortcomings, IMHO has it enabled will be faster in all cases?

Found original post:

Quote:

@kas1e

https://github.com/AmigaPorts/SDL/blob/master/WhatsNew.txt#L22

There is a catch, it's only enabled for default. So if you are somehow specifying that you want "opengl" or whatever, it deactivates as far as I understand.

So you may need to supply a hint or env var.

@Capehill
Ok, got it ..

Another question : is "compositing" renderer which we have in sdl2 give us scaling functionality "for free", just like overlay do before, or, its just "redenrer of sdl2", and to have "free scaling" i need to implement "compositing" output for DOSBox ?

@kas1e

Quote:

Yes, and rotating and alpha blending of bitmaps.

@Capehill
So, if I run DOSBox with "output=surface", and in the console have SDL2 render use "compositing", then it means I have no needs to implement anything because scaling already for free there.

That probably explain why I didn't notice any difference in speed loose when using "normal" scaling like 2x, 3x or even 4x. Only see a difference when using hq2x, mame, and other scalers which at top of pure scaling add some effects which take CPU.

But will recheck it all to be sure. Will try for example set renderer to software, and see how scalers will behave on cpu loading.

@Capehill
Yep, it seems compositing deal with it!

Tested just this running DOSBox, and keep a pure window open doing nothing (so all in window mode):

1). scaler=none
compositing: 0% cpu, software: 3% cpu

2). scaler=normal2x:
compositing: 0% cpu, software: 16-18% cpu

3). scaler=normal3x:
compositing: 0% cpu, software: 33-36% cpu

4). scaler=hq2x:
compositing: 0% cpu, software: 16-18% cpu

5). scaler=hq3x:
compositing: 0% cpu, software: 34-37% cpu


In other words any scaler I try gives 0% loading on SDL2's compositing and up to 40% CPU loading in SDL2's software. I was under impression that at least "hq2x" and "hq3x" ones will take some CPU, but nope. What a relief ! It means we have no needs to have OpenGL mode at all in DOSBox, as it was usably for those ones who didn't have "free scalers".

EDIT: And about colors issues: sorry yesterday was false alarm. After it all take much hype and noise it was fixed inside of DOSBox, yeah!

@Capehill
So i back to the last problem in DOSBox called "opengl". Now, after i do more tests, i can say that with opengl everything slower because it hit 100% cpu.

That happens just with pure MiniGL, or with GL4ES (so ogles2/warp3dnova) all same. I think reassons there can be 2:

1). We lack DMA, so we fast hit CPU limit when opengl works and those things slow everything down.

2). It can be not just lack of DMA, it can be just problem with whole texture uploading in warp3dnova, because then why when we upload textures via pure OS functions (which on x5000 also, without DMA), everything fast ?

I by some luck was able to speed up it a bit by playing with some dosbox's options, but the same settings over compositing output and over opengl/ogles2 always slower does not matter what and hitting of 100% CPU happens much offten.

That we can later debug/check/profile to find out wtf exactly. Maybe making some pure test-cases will help at least to think about creating some reports, or find the roots.

And have 2 issues with DOSBox and opengl (minigl in that case) not related to speed.

1. On exit from DOSBOx when i set "output=opengl" in DOSBox conf, i always meet

----
Parent process has tried exit before all children have

Process: "dosbox"
Function: "Wait_Until_Child_Ends()"
Error Process: "MiniGL watch-dog <pid=xxx>
----

Its just enough to run DOsbox and while it load things exit from (so interrupt some process , maybe texture loading, dunno).

2. If i run dosbox without config file, and do "setenv SDL_RENDER_DRIVER opengl" , then i have "white window" in both window and fullscreen modes. doing "setenv SDL_RENDER_DRIVER compositing" , or "setenv SDL_RENDER_DRIVER software" works fine without config.

"opengles2" driver didn't have such issue. Just all muared as "blue" as you know (is it should be fixed inside of warp3dnova?), but not fully white window. So i assume its issues with opengl renderer only in SDL2 (at least, if compositing, software and opengles2 works..).

Btw, and when i have in "opengl" renderer mode that white window after running, closing the window give me the same "waitchild" process error as i explain in 1).

@kas1e

I don't know Dosbox yet so I don't know what things it's doing, regarding OpenGL drawing. If hieronymus works on Pegasos, can you try it there to see?

But regarding watchdog issue, that seems an easy bug: DosBox doesn't call SDL_GL_DeleteContext when exiting. SDL_GL_DeleteContext is only called when DB wants to set a new display.

Regarding whitescreen issue, try to find out does DB use NPOT textures. And check GL errors at the end.

@Capehill

Quote:

Sadly but Hieronymus also didn't work on Pegasos :(

From latest changelog entries of Hieronymous:

Version 0.21 (2013-10-05 "AmigaOne G4 release")
- Added support of AmigaOne models with a G4 processor, that was omitted by mistake. Pegasos 2 is detected too but not supported.

I will ask Mathis if it possible at all to allow peg2 to use "-pg" route, as perfomancemonitor() in kernel have support for as i remember from last discussions

Quote:

Oh you are right! Just added this:



And bug is gone. Thanks!

But what is intersting, bug is gone if i run dosbox with just "output=opengl". If i set "output=surface", and set "SDL_RENDER_DRIVER" to opengl, then i catch a white screen, and then, quiting from dosbox giving me the same "watchdog" issue! So seems when we do "output=opengl" or just set renderer to opengl while output=surface, dosbox and sdl2 go different routes for sure.

Quote:

Don't know if it helps us to rule out NPOT, but I tried to just run DOSBox in window mode in 1024x1024 (so POT), and the white screen still there.

I also tried minigl4gl4es (so, to check MiniGL which works over olges2/warp3dnova, and not original one working over Warp3D SI), and via MiniGL4GL4ES have the same issue.

The only file in DOSBox which use OpenGL at all is there "src/gui/sdlmain.cpp" file (C_OPENGL ifdefs).

See here how it looks like with SDL2 on top now (as in repo its SDL1 one): http://kas1e.mikendezign.com/aos4/dosbox/sdlmain.cpp

But "white bug" happens and for SDL1, and for SDL2.

Also, opengles2 renderer didn't have that "white" issue, while it also works over warp3dnova (like minigl4gl4es, which have that white issue same as original minigl working over warp3d SI driver).


EDIT: oh, forget to answer you on some previous post:

Quote:

Yeah DOSBox-staging compiles for os4 natively and all works, but I use pure DosBox original code, with just apply 4 patches for now:

1). PPC jit
2). some more endian fixes for fat_drivers
3). adding of normal4x,5x and 6x scalers
4). SDL2 migrate path

I use original to avoid catch new bugs happens in "staging" fork which may surely happen, they add a lot of non-need it stuff, etc. New bugs, new problems as usual. That fork mostly used for testing bugs, making patches, and then pull-request it to the core, if some of them will be accepted.

But fully compiled "staging" work (with their own version of SDL2 code applied to sdlmain.cpp) and it fail the same with a white screen.

More of it, that "DOSBox-staging" has added new options for DOSBox "texture_output=", and so, in this case, I even didn't need to play with "SDL_RENDER_DRIVER" environment, for me its enough to just set "output=opengl" and "texture_output=ANYTHING" to have reproduced that "all-white" issue. That why I said before that you probably right when say "it seems something about textures setup"

@Capehill
Also found with latest RC1 release, that versions didn't changed everywhere. I.e. for:



And then printf those: sdl_compiled.major, sdl_compiled.minor, sdl_compiled.patch, sdl_linked.major, sdl_linked.minor, sdl_linked.patch);


I will have for first 3 values 2.0.9 in return, , and for second 3 2.0.11 , while first 3 also should be 2.0.11 probabaly ?

@kas1e

Have you installed the latest headers? https://github.com/AmigaPorts/SDL/blob ... include/SDL_version.h#L62

@Capehill

Installed those ones from RC1, and inside there old includes from 2.0.9 (at least version.h for sure). Probably forgot to update them for RC1 ?

@kas1e

Yes, my bad. Thanks. Will fix for RC2.

@Capehill

Thank you for the timer fix.
Looking forward to RC2

@Raziel

https://github.com/AmigaPorts/SDL/releases/tag/v2.0.11-rc2-amigaos4

@Capehill

Slowdown and keyboard key issue fixed

Thanks a lot

...

@Capehill
Have some theoretical question:

In DosBox we have such possible outputs from config: surface (so what SDL2 choice), OpenGL, overlay and DDraw.

Now, in all the cases, except the surface, when I set the size of fullscreen or of a window it is scaled to the size I chose (without needs to apply any external scalers, etc).

Everything handled there:

http://kas1e.mikendezign.com/aos4/dosbox/sdlmain.cpp

For sdl.desktop.want_type (at least for SDL1), it can be SCREEN_SURFACE, SCREEN_SURFACE_DDRAW, SCREEN_OVERLAY, and SCREEN_OPENGL.

So, as our SDL2 can use compositing (which in general same as Overlay, just better, right?), I want to implement "compositing" output, so in hope, it will works then the same as all other outputs and do scaling, just all "scaling" will work for window and fullscreen without external scalers, and without speed loose (as it compositing).

Or, I think that if our SDL2 set compositing anyway when I choose "surface", then maybe I can just in case SCREEN_SURFACE adds something so it will think that we can do "scaling" like for OpenGL, DDraw and overlay?

Why I want to implement this, because with a pure surface as it now, I can't scale whole DOSBox output to any size I need, and I must use external DOSBox scalers, which also didn't fit well in any resolution I want.

What do you think?

Imho scaling didn't happen when I use "surface" only because of DOSBox's code, which thinks that when the surface is used, we can't do scaling (strange why through..)

@kas1e

I haven't had time to test your DosBox port but I think you are missing the most important output, "texture". SCREEN_TEXTURE is what creates the SDL_Renderer which itself can have multiple backend options, including compositing.

Surfaces in SDL2 are software only and if there is any scaling to do be done, it must be implemented by the application.