SDL2

@Capehill

With the new prefs program...what would be the "best" setting for "Driver".

"Compositing" should have the lowest impact, since it's integrated into the system.
What about opengles2?

@Raziel

I would use default (no SDL_RENDER_DRIVER file) which will end up being "compositing" in practise.

"opengl" is the most crippled one. Main reason is the lack of render target.

"opengles2" and "software" have most features, especially the blending modes.

@Capehill

Thank you

Looking at the prefs program now

Some requests for the next release, if i may?

1) Since "compositing" is always default, could you drop the "default" setting entirely and use the second option "compositing (default)" as default?
2) Could you add a "(not 100% supported)" to the "opengl" target?
That way people would know that it should be the least usable option.
Maybe add the reason in bubble help (lack of render target, no FBO etc.)
3) Could you gray out "Batching Mode" for "opengl" and "compositing" (they don't use it, if i understand it correctly)?

And another question
What is "Batching mode"?
What does it do, what is the benefit?

And a final question
Would the SDL2 prefs editor be out of scope for the LIBGL settings from gl4es/opengles2?
Like LIBGL_VERSION, LIBGL_VSYNC and such?
Then we could have all the possible options in one prefs?
(And of course, grey them out, if gl4es/opengles2 is not used)

And it would match too, since opengles2 is a driver.

Thank you

@Raziel

1) I wouldn't want to drop default because IMHO we need a "normal" way of operation when there are no settings forced by the user. Even if the normal mode happens to be the same as "compositing" mode (today).

2) Sure. There is something in the readme file, too, but I should know by now that people don't read mes. Going to rename to IgnoreMe :)

3) Yes they use. But not all applications can benefit from batching. If your application draws 1000 lines or sprites per frame, then it might benefit from reduced draw calls. But applications that do only one RenderCopy (ScummVM, Lite-XL, MilkyTracker) cannot get anything from batching because there is nothing to "batch".

But if you have some bullet hell shooter, that's a good candidate for gains.

LIBGL: there are quite many variables in documentation https://github.com/ptitSeb/gl4es/blob/master/USAGE.md . I think I have to skip these due to effort needed.

@Capehill

Understood

Thank you

@Capehill

Quote:

Thank you for keeping it up to date! Works great so far!

SDL2 2.0.20 RC1 introduces some nice autoscaling feature. So a Game that opened a 640x480 Screen before (linked to SDL2 2.0.14 U1) is now being shown on a Screen with the same resolution like the Workbench Screen. This is pretty cool for 4:3 Games as they are being rendered correctly now on a widescreen monitor (without the need to adjust input signal) keeping original aspect ratio with addition of black borders to the left and right.

I would like to know which parameter/flag/hint is responsible for this because not every game linked to 2.0.20 RC1 shows this behavior.

@IamSONIC

I haven't tested but I'm guessing SDL_RENDER_LOGICAL_SIZE_MODE - https://github.com/libsdl-org/SDL/blob ... include/SDL_hints.h#L1128


@All

RC2 is available - https://github.com/AmigaPorts/SDL-2.0/releases

Changes:

Quote:

@Capehill

Here an icon to include for the prefs :)

https://we.tl/t-cnaao82n9S

A couple of things more to adjust maybe

1) "About" string in prefs menu could be "About..."

2) Prefs should be set as opened by default in Workbench instead of shell

@Capehill

Quote:

Thanks. To set game resolution automatically to desktop resolution the flag "SDL_WINDOW_FULLSCREEN_DESKTOP" needs to be added to the window flags. SDL_RENDER_LOGICAL_SIZE_MODE can then be used to control scaling behavior.

@Capehill

In prefs, you can "limit" button height by adding "CHILD_WeightedHeight, 0," to the button group:

I'm trying to use SDL2 with GLES2 and i get this error:

Failed to create OpenGL ES 2 context

What can cause this problem? Of course GLES2 is working correctly on my system (like shaderjoy for example).
Do I have to set something?

@jabirulo

Yeah, good point. Done.

@IamSonic

Added this setting to the GUI. Still haven't tested with any apps yet.

@samo79

Thanks for the icon.

@afxgroup

Do you have a small test case?

@capehill

Cool, i am still experimenting with this feature. I intend to support it optionally in upcoming releases.

@IamSONIC

It doesn't seem to work properly when using the compositing backend. It seems that there is no rendering (black window). I need to debug it a bit.

@Capehill

Interesting! Setting SDL_HINT_RENDER_LOGICAL_SIZE_MODE to "0" / "letterbox" works on my machine using compositing renderer. I get some random flickering when using OpenGL ES 2 renderer.

However i get a black or grey screen when using "1" / "overscan" using compositing renderer. It works using OpenGL ES 2 renderer, but the resulting image doesn't looks like as supposed to look like: "Will zoom the rendering so it fills the entire screen, allowing edges to be drawn offscreen".

@IamSONIC

Please try to enable batching for OpenGLES 2. IIRC some SDL2 internal test programs show flickering output without batching. Need to debug also that some day.

@Capehill

Enabled Batching. Now the resulting image is not just flickering also some strange scaling problems of single textures appeared.

@IamSONIC

Just found out that a negative value is passed from cliprect to COMPTAG_DestY which causes blank window. Will investigate more next week.

Regarding OpenGLES 2 batching, strange! Well, it seems that ogles2.library update may be coming so need to retest again after that.

RC3 is available now: https://github.com/AmigaPorts/SDL-2.0/ ... /tag/v2.0.20-rc3-amigaos4

Quote:

@Capehill

Good job

Tested RC3... works great! Logical size mode seems to work now as expected.